Skip to main content
Every non-2xx response returned by /v1/* carries the same JSON error envelope describing what went wrong. Every error — whether it originates in a handler or in middleware (authentication, permissions, rate limiting, idempotency, request timeouts) — includes a human-readable message and a machine-readable code your client can branch on.

Standard error envelope

Validation error envelope

Requests that fail field-level validation return 422 Unprocessable Entity with a details array. Each entry identifies the offending field and what it needs.
The field is dotted-path notation for nested objects (for example individual.address.country). Fix every entry in details and retry.

HTTP status reference

The X-Request-ID header

Every response includes an X-Request-ID header. This ID is generated by the API when a request arrives (or echoed from the client when you set one on the request). Include this value when opening a support ticket — Anton retains the server-side log for every request keyed by this ID, and we can trace the failure without asking you to reproduce it.

Error code catalog

The following codes are returned via the code field of the error envelope. Codes not listed here do not currently exist in the API — the merchant-facing surface has a small, deliberate set.

Authentication

Authorization and access

Validation

Resource not found

404 Not Found responses always carry a code identifying the missing resource. Anton never distinguishes “does not exist” from “exists but belongs to another merchant” — both return the same *_not_found envelope to prevent tenant enumeration.

Idempotency

Rate limiting

Payouts

payout_rejected sub-causes

payout_rejected is a stable, coarse-grained code — your integration should pattern-match on error.code, not on error.message. Today it rolls up the following conditions in the API response. The message string distinguishes them, and the operational runbook (api/docs/internal/integrations/) carries the full mapping. Future API revisions may split any of these into a dedicated code; when that happens it will be announced as a breaking change with a minimum 90-day deprecation window on the catch-all.

Stable failure codes on payout events

A payout that fails after creation (during asynchronous rail submission) transitions to failed and records a sanitized failure on its event timeline. Read it from GET /v1/payouts/{id}/events — the terminal event’s metadata carries: On every terminal failure the full reserved amount (source + fees) is released back to your available balance, and a payout.failed webhook fires. The webhook payload carries the payout resource; fetch the events endpoint for the failure_code.

Intelligence

The strict Intelligence request contract returns two codes beyond the standard set. See Intelligence — Rate Limits and Errors.

Batches

Uploads larger than the 32 MB limit currently surface as 400 file_too_large (the BodySizeLimit middleware rejects oversize requests before the handler runs). The catalog entry in the Payload size section reflects the intended long-term shape (413 file_too_large); an internal fix is tracked to align the status.

Beneficiaries

Beneficiary rescore

Codes returned only by POST /v1/beneficiaries/{id}/rescore.

Instruments

FX

Webhook subscriptions

Structured codes returned by POST /v1/webhooks:

Payload size

Sandbox-only

These codes are returned only by the /v1/merchant/sandbox/* routes, which are registered only in sandbox-class environments. Production merchants will never see them.

Server and infrastructure

Retry semantics

Not every error is safe to retry. The table below is a safe default — apply stricter rules where your integration’s correctness depends on it.
When retrying a mutating request (POST, PUT, PATCH), always send the same Idempotency-Key you used on the original attempt. Without it, the server cannot distinguish a retry from a new request, and you risk double-processing. See Idempotency.

Handling errors in code

When contacting Anton support about a failed request, include the X-Request-ID header value from the response. Anton retains a full server-side trace keyed by that ID and can diagnose without asking you to reproduce.