Skip to main content
Every error response carries both an HTTP status code and a stable numeric code you can switch on programmatically. The shape is:
Always log 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.failed events — when an endpoint exhausts its retry budget.
If your endpoint returns 410 Gone, Qustody marks it DISABLED permanently. Recreate it to resume deliveries.