Resolve a customer credential to a CustomerContext
The canonical identity-resolution resource. Accepts one of five credential types (discriminated by credential_type: phone | card_fingerprint | short_code | provider_customer_id | qr) and resolves the customer to a CustomerContext carrying their wallet state, promo balance, wallet program binding, and an identity_trace_id for downstream correlation. Returns one of three resolution states: registered (fully enrolled, balance readable), pending_proof (enrolled but not yet identity-verified, balance visible but spend gated by the POS), or not_found (no wallet identity for this credential under this enterprise). A credential that matches a customer enrolled in multiple active programs returns WALLET_PROGRAM_AMBIGUOUS (HTTP 422); the error body lists the candidates so the caller can present a disambiguator. This endpoint never returns a debit token, an authorization token, or any artifact that permits a ledger mutation. The session-anchored variant, which writes the resolved identity into an open checkout session, is POST /checkout/sessions/{id}/identify. Use this standalone endpoint for balance-check panels, cashier lookup screens, and POS-display use cases where there is no active checkout session. Rate-limited per integration to prevent enumeration attacks; a 429 response carries Retry-After and X-RateLimit-* headers.
Authorizations
Partner API key (platform- or merchant-scoped). Contract key-enforces context.merchant_id.
Headers
OPTIONAL on this operation, it is a side-effect-free read behind a POST (the body carries the query). Reads are naturally idempotent, so no dedup key is required for correctness. If you send the header anyway (e.g. uniform client middleware that stamps every POST), it is accepted and replays are reported via meta.idempotency_replayed. Mutating operations use the REQUIRED IdempotencyKey parameter instead.
Body
Body for POST /identify. Carries exactly one credential (discriminated by credential.credential_type). No checkout session context is required, this is the standalone identify. For the session-anchored variant use POST /checkout/sessions/{id}/identify.
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.
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.
Discriminated-union credential. The credential_type field selects the variant. Exactly one credential field must be present alongside credential_type.
- Option 1
- Option 2
- Option 3
- Option 4
- Option 5
Response
Customer resolved. Inspect data.resolution_state for the resolution outcome: registered, pending_proof, or not_found. The not_found state is returned as HTTP 200 with a null balance (not 404) so polling UIs can distinguish 'no wallet' from a server error.
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.
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.
The identity-resolution result. Returned by POST /identify and the session-anchored POST /checkout/sessions/{id}/identify. This object never contains a debit token, authorization token, or any artifact that permits a ledger mutation: identity resolution is read-only and cannot, by itself, move funds. The resolution_state field carries the resolution outcome (registered, pending_proof, or not_found); an ambiguous match returns WALLET_PROGRAM_AMBIGUOUS (HTTP 422). The balance field is null when resolution_state is not_found.
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.