Hard-delete an API key (deprovision / error cleanup)
Permanently delete an API key record (deprovision a retired terminal or clean up a provisioning error). Modeled as POST (not HTTP DELETE) so it carries the canonical envelope and Idempotency-Key header uniformly with the rest of the mutating surface. After delete, the key fails verification and no JWT can be minted; unlike revoke, the record is removed (use revoke for a reversible, audited soft state, and delete for true deprovisioning). The audit event is preserved even though the record is removed. Idempotent on the Idempotency-Key header and idempotent by nature: deleting an already-deleted key replays a deleted-state result rather than a 404 when the same idempotency key is reused; a fresh request against an unknown id returns NOT_FOUND. The Idempotency-Key (not the key id) governs this outcome: replay of the original key returns 200, any fresh key against a removed record returns 404. Tenant-scoped: another integration’s key resolves to NOT_FOUND (404). Requires the integrations DELETE 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 delete.
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
Key deleted (or idempotent replay of a prior delete).
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.
Compact result of a revoke/delete. status reflects the post-operation lifecycle state.
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.