Rotate an API key: revoke + reissue same scope, raw key shown once
Zero-downtime rotation: atomically revoke the old key and issue a new raw key, preserving the same scope (enterprise, brand, or branch) and label. After rotation the old raw key fails verification immediately and the new raw key works. The new raw key is returned exactly once in this response, with the same one-time semantics as create. The audit trail records both the old key id (revoked) and the new key id. Note for operators: rotation is immediate with no overlap grace window for in-flight requests still presenting the old key, so sequence the POS terminal swap accordingly. JWTs already minted from the old key remain valid until their own 600-second TTL expires (there is no JWT revocation list, the same window as revoke), so a key-compromise response must assume up to 10 minutes of residual terminal sessions. Idempotent on the Idempotency-Key header: a retried regenerate replays the same new key bytes rather than performing a second rotation. Tenant-scoped: another integration’s key resolves to NOT_FOUND (404). Requires the integrations UPDATE permission.
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).
Path Parameters
The API key id to rotate.
Body
Generic envelope for a no-body key mutation (revoke / regenerate / delete). The canonical envelope plus an optional audit reason.
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 human-readable audit reason (e.g. 'terminal_decommissioned', 'scheduled_rotation').
200Response
Rotated. raw_key is the NEW key, present only in this response (or an idempotent replay).
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 result of rotating a key. Same one-time raw_key semantics as create; also returns the deleted predecessor's id for the audit trail.
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.