Skip to main content

Error response format

ABP returns errors in two shapes, depending on where the error originates:
  • Auth / rate-limit middleware errors use an error key:
  • Application / route errors (validation, not-found, etc.) use the FastAPI-standard detail key:
Handle both shapes in your client. Request-body validation errors (422) include field-level detail with a loc path:

HTTP status codes

Order decline reasons

When placing orders via POST /place-orders, orders that fail business validation are returned in the declinedOrders array (not as HTTP errors). Each declined order includes a declineReason:
Duplicate requestUuids are not returned as decline reasons. A duplicate is silently skipped; if every order in the request is a duplicate, the request returns 409 instead (see below).
Example declined order response:

Common errors

Authentication (401 / 403)

Forbidden (403)

Returned when the API key header is missing, when the key is not allowed for the requested endpoint/sport/bookmaker, or when you attempt to access a resource that belongs to a different client.

Duplicate request (409)

Returned only when every order in the request is a duplicate — each requestUuid was already processed or is in progress within the last 30 minutes. If only some orders are duplicates, those are skipped and the rest are processed normally.

Validation error (422)

Request body contains invalid data. Check the loc field for the problematic path:

Rate limiting (429)

Exceeded requests per second for your client. Default limit: 100/second (configurable per client).
The window resets every second — wait the retry_after interval before retrying.

Resilience patterns

ABP implements several resilience mechanisms that may affect your integration:

Circuit breakers

Per-bookmaker circuit breakers prevent cascading failures. If a bookmaker is experiencing issues, orders targeting that bookmaker may be declined until the circuit recovers. Opens after consecutive failures, automatically tests recovery, and resumes normal operation once the bookmaker responds successfully.

Emergency mode

In rare cases, the system may temporarily pause order processing during maintenance or upstream issues. The emergency WebSocket channel broadcasts status changes.

Order expiry

Orders have a default expiresAt of 5 seconds from creation (capped at 24 hours maximum). If a bet hasn’t been placed within this window, the order status changes to EXPIRED. Set a custom expiresAt for longer-lived orders.

Next steps

Order Placement

Understand fills, partial stakes, and decline reasons.

WebSocket

Track order and bet status in real time.