Exchange an API key for a short-lived POS terminal JWT
Exchange a long-lived x-api-key (presented in the x-api-key header) for a short-lived POS terminal JWT (HS256, 600-second TTL) that the terminal uses on cashier-scoped money and identity calls. The JWT carries scope claims derived from the key (integration_id, enterprise_id, brand_id, branch_id), an optional server-validated cashier_id (max 64 chars, no control characters, validated rather than trusted from the body alone), and a sandbox claim mirroring the key. The terminal JWT is domain-separated from the consumer JWT (distinct issuer/audience and a versioned signing context), with iss=feddi-pos-terminal and aud=feddi-api, so a consumer JWT can never be mistaken for a POS terminal JWT and vice versa. A revoked or expired key, or a key whose integration is not ACTIVE, returns INVALID_API_KEY (401). This is an authentication exchange, not a money or identity-resolution call: it returns a JWT, never a debit token and never customer PII. Idempotent on the Idempotency-Key header: a retried exchange within the validity window replays the same JWT.
Authorizations
Partner API key (platform- or merchant-scoped). Contract key-enforces context.merchant_id.
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
Exchange the x-api-key (header) for a short-lived POS terminal JWT. The raw key is in the x-api-key header, NOT the body.
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 canonical context block. merchant_id is key-enforced to a merchant the caller is authorized for, never a free-text trust field. cashier_id is server-trusted only when it is signed into the terminal JWT.
Optional cashier identifier to embed in the JWT scope. Server-validated: ≤ 64 chars, no control characters. Trusted only because it is signed into the JWT here. AUTHORITATIVE on conflict: when context.cashier_id is also present, THIS top-level field is the one signed into the JWT; the context copy is telemetry only.
64Response
JWT minted. Domain-separated POS terminal token with scope claims.
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.
A minted short-lived POS terminal JWT (HS256, 600s) + its decoded scope. Domain-separated from the consumer JWT (iss=feddi-pos-terminal, aud=feddi-api). NEVER a debit token and NEVER carries customer PII.
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.