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 is200 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.