Skip to main content
Errors are returned either for the entire request or for an individual item in a batched exchange action. Clients must handle both forms.

Request Errors

A rejected request normally returns a non-200 HTTP status and a machine-readable code:
field, intentId, and retryAfter are included only when relevant. Some read endpoints return the older { "error": "..." } shape without a code. Error messages can change; use code for program logic when it is present.

Error Codes

Batched Action Errors

Order, cancel, and modify results normally contain one status for each item in the request. An individual item can fail even when the HTTP status is 200 and the top-level status is ok:
Inspect every item in response.data.statuses. When present, metadata.results also contains the Notional order ID and the corresponding status. Some errors apply to the whole payload, such as an invalid signature, a reused nonce, or malformed batch data. These are returned once as a request error rather than once per item. A batching client must therefore support both a single request error and an array containing item-level errors.

HTTP Statuses

For 429 and 503, respect the Retry-After header when it is present. Do not retry other 4xx responses without changing the request. After a timeout, disconnect, or 500, check the current account and order state before submitting a new signed action. For orders, use Open Orders and Historical Orders. /exchange responses can include X-Request-Id, X-Client-Request-Id, and X-Transaction-Id. Record these values when reporting an unexpected failure.