Skip to main content
Use error.code to decide how to handle a failure and keep request_id for troubleshooting. The sections below describe the response format, retry behavior, rate limits, and individual codes.

Error categories and customer actions

These categories group errors by the action a customer can take. They are documentation categories; the response does not yet include a category or retryable field. error.type describes the existing exception family and is not a substitute for error.code.

Message and detail visibility

  • code is the stable value for programmatic handling. Message wording may improve without changing the code.
  • message explains the customer-visible problem. Messages do not identify payment or custody vendors or reproduce their raw errors.
  • details carries useful customer context such as a field, currency, network, resource ID or limit. Internal routing, provider identifiers and gateway responses are omitted.
  • Legacy application codes on 4xx errors retain their messages and safe context. Unknown 5xx and gateway codes map to public error-family codes; explicit customer messages are preserved. Fee and onboarding codes retain their existing wording.
  • Support can correlate request_id with internal diagnostics. Internal diagnostics are not part of the customer response.
Wallet limit errors retain currency, network and counts; see Create a wallet.

Messages for common recovery paths

These are current default messages, not strings applications should match. Endpoint-specific validation messages can be more detailed.

Error response format

Every error returns the same envelope:
string
The family of the error: unauthorized, access_denied, kyc_not_approved, validation_error, service_validation, business_rule, delete_blocked, resource_not_found, insufficient_funds, rate_limit_exceeded, request_too_large, gateway (and its gateway_* variants), service_unavailable, or a server-side failure (service, internal_error, configuration).
string
The specific code, always UPPER_SNAKE_CASE. Branch on this value.
string
Human-readable explanation. The wording can change; do not parse it.
object
Structured context, present only on codes that carry it. The keys are listed with each code below.
string
Identifier for this request: your X-Request-ID header when you send one, otherwise a UUID Hop generates. Quote it when contacting support.
Schema validation failures (422 VALIDATION_ERROR) add a validation_errors array naming each offending field, in dot notation for nested fields (platform_fee.amount, address.country); a missing required header appears there under the header’s name:

HTTP status codes

Retrying a request

Check the error code before retrying: For endpoints that support Idempotency, keep the same key and body. Otherwise, check whether the operation succeeded before submitting it again. Generate fresh authentication headers for each attempt. Failure and recovery covers the procedure for each operation.

Rate limits

Rate limits are applied per API key, per minute, using a fixed clock-minute window. The default is 1000 requests per minute; your key’s limit is set when the key is issued and can be anywhere from 1 to 10000. Exceeding it returns 429:
The response does not carry a Retry-After header today. The counter resets at the top of the next clock minute; sleep until then and retry. If you need a higher limit, contact support.

Error code reference

Authentication and access

Request validation

Idempotency

Money movement

Foreign exchange

Transfers, virtual accounts and wallets

Approval and operation outcomes

Service failures