code you can switch on programmatically. The shape is:
request_id — it lets Qustody operators trace the full request path.
Code ranges
Authentication and authorization (1000–1099)
Recovery: verify the bearer token, check the user’s role assignments via
GET /v1/users/{id}/roles, or rotate the API key with POST /v1/credentials/rotate.
Validation (1100–1199)
Recovery: fix the input. Validation errors are not retryable.
Policy and approval (1200–1299)
Recovery: for
1200, modify the request or update the policy. For 1201, route the transaction to the appropriate approvers.
Transaction lifecycle (1300–1399)
Recovery: for
1301, fetch the latest state with GET /v1/transactions/{id}. For 1302, confirm the signer is using the correct key. For 1303 and 1304, cancel the transaction and resubmit.
Vault and resource (1400–1499)
Upstream node and chain (1500–1599)
Recovery: retry with exponential backoff. If
CUSTODY_NODE_BACKUP_RPC_URLS is configured, Qustody fails over automatically.
Server / infrastructure (1600–1699)
Recovery: for
1600, retry once after a short delay; if it persists, contact support with the request_id. For 1601, generate a fresh idempotency key. For 1602, respect the Retry-After header and consider a Redis-backed limiter for cluster deployments.
Retry policy
Always include an
Idempotency-Key on retried mutating requests so the server collapses duplicates.
Webhook delivery errors
Webhook delivery failures don’t surface to the API caller. They appear in:GET /v1/webhooks/{id}/deliveries— per-delivery status, last response code, retry count.webhook.delivery.failedevents — when an endpoint exhausts its retry budget.
410 Gone, Qustody marks it DISABLED permanently. Recreate it to resume deliveries.