Skip to main content
POST
Cashier-initiated enrollment: create a PENDING_PROOF wallet + SMS a verification link

Authorizations

Authorization
string
header
required

POS terminal JWT minted by /auth/token; carries integrationId + terminal/cashier claims (server-trusted).

Headers

Idempotency-Key
string<uuid>
required

Partner-generated UUID; the ONE dedup key for all mutating endpoints. 24h TTL. Same key + same payload -> byte-identical replay; same key + different payload -> IDEMPOTENCY_KEY_REUSED (422).

Body

application/json

Body for POST /enroll/initiate. The cashier supplies a phone (E.164-normalized server-side) and optionally the POS provider customer-id.

context
object
required

Canonical request context, shared across all partner domains. merchant_id is key-enforced to a merchant the calling credential is authorized for (a platform-scoped credential acts only on its own tenants), so it is never a free-text trust field: a merchant_id outside the credential's authority is rejected rather than honored.

phone
string
required

The customer's phone; normalized to E.164 server-side. The identity key is (merchant_id, normalized_phone).

meta
object

Common request metadata shared across all Partner API domains. partner_request_id is a correlation identifier only: it appears in logs and responses for tracing but is never used as the deduplication key. Request deduplication is keyed exclusively on the Idempotency-Key header.

provider_customer_id
string | null

The POS provider's customer id; bound to the wallet identity at verify (provider-customer link), not at initiate.

wallet_program_id
string | null

Explicit program when the customer could map to several; NULL uses the integration's current assignment. Ambiguity → WALLET_PROGRAM_AMBIGUOUS.

language
string | null

Preferred SMS language (e.g. en, ar); defaults to the program/branch default.

Example:

"en"

Response

PENDING_PROOF proto-wallet created (or idempotent replay) and the verification SMS dispatched. No money moved, no provider-customer link yet.

The standard response envelope that every enveloped endpoint serializes through. ok is a boolean discriminator: when ok is true, the typed result is carried in data; when ok is false, a typed error object is returned instead. The meta object is uniform across the entire API surface.

ok
boolean
required
meta
object
required

The uniform response metadata block returned on every response. data_completeness_score is computed per call and reports the completeness of the returned data. decision_trace_id is present on responses that carry decision or insight output and can be used to correlate the response with its reasoning. capabilities is an additive, response-level array of hints advertising features the caller may use, and may be extended over time without notice.

data
object

Result of POST /enroll/initiate. The customer's wallet identity now exists in a PENDING_PROOF state and a verification SMS has been sent to the supplied phone number. No funds move during initiation, and the provider-customer link is not yet established. The link is created only once the verification step completes.

error
object | null

The typed error object returned with every non-2xx response. code is a string enum (for example WALLET_PROGRAM_AMBIGUOUS, CREDENTIAL_TYPE_UNSUPPORTED, INSUFFICIENT_FUNDS, IDEMPOTENCY_KEY_REUSED, CURRENCY_NOT_SUPPORTED), never a bare HTTP status number. Inspect code for programmatic branching, not the HTTP status. Some codes echo the valid set in details so clients can present or reconcile the accepted values: for example CREDENTIAL_TYPE_UNSUPPORTED lists the supported credential types, CURRENCY_NOT_SUPPORTED lists the supported ISO-4217 currencies, and WALLET_PROGRAM_AMBIGUOUS lists the candidate wallet_program_id values that matched the request.