Drive the claim release-engine: release a PENDING_PROOF proto-wallet's LOCKED promo grants
Drives the claim release engine, which converts a registered customer’s LOCKED cashback-class promotional grants into spendable promo balance. The claim is modeled as a state-machine resource: an idempotent POST advances each eligible grant. The engine loads the resolved customer’s pending grants, applies the claim-gate policy, flips LOCKED (and PENDING) grants to RELEASED, and credits the resulting promo balance in a single atomic operation. Release is gated on a verified customer: a LOCKED grant is never released by an anonymous-to-identity merge alone, only by proof-of-phone verification plus claim-gate satisfaction. Resolve the customer by wallet_user_id or by an identity credential.\n\nThis path converges across the six possible event orderings of (register, top-up or cashback accrual, claim): register-before-accrual and accrual-before-register both converge to the same released balance, claim-after-clawback releases 0, a duplicate claim is a no-op replay, and concurrent claims collapse to exactly one creditor (atomically, one creditor). Verification of phone ownership invokes this engine inline for the common path; this explicit endpoint exists for operational re-drive and for the top-up-before-register ordering, where verification already happened but a later accrual still needs releasing. Idempotent on the Idempotency-Key header: a retry replays the original result. Cross-tenant targets resolve to FORBIDDEN (403) or NOT_FOUND (404).
Authorizations
POS terminal JWT minted by /auth/token; carries integrationId + terminal/cashier claims (server-trusted).
Headers
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
Body for POST /claims. Resolve the customer by wallet_user_id OR identity credential (at least one 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.
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.
The VERIFIED wallet identity whose LOCKED grants to release.
An identity credential used to resolve a customer, shared across all partner domains. The object is discriminated by credential_type, and the value field matching the declared credential_type is REQUIRED (enforced by per-type conditional schemas: a credential without its matching value field is invalid). The set of supported credential_type values is enumerated by GET /capabilities. New credential types are added additively: a new type appears in the GET /capabilities set without any route change. A credential_type that is not in the supported set returns CREDENTIAL_TYPE_UNSUPPORTED, and the error response lists the currently supported set.
Response
Claim resolved, eligible LOCKED grants released and credited (or idempotent replay; or 0 released when nothing was claimable / all clawed back).
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.
State of the claim resource. state is the claim-state-machine value; the grant breakdown shows what released vs was skipped (e.g. clawed-back / not-yet-verified).
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.