Rate limits

The API meters requests in budgets. Over a budget, a call is refused with 429 and a Retry-After header instead of being served. The budgets below are the defaults; Bullionwale’s limits for your account may differ.

Budgets

Budget	Default	Counts
Reads	300 per minute, per key	Every `GET`.
Orders, per key	60 per minute, and at most 10 per 10 seconds	Every `POST /orders`, replays included.
Orders, per account	60 per minute, per account	Production only. Every `POST /orders` from all of the account’s keys together, replays included, so two keys (or a rotation overlap) do not double it.
Failed authentications	20 per minute, per source address	Every call refused with a `401`, from any key.

Reads and orders are separate. Polling GET /orders/{order_id} never uses your order budget, and placing orders never slows your reads.
Budgets are per key. Give each system its own key and it gets its own budget.
Replays count. Resending a POST /orders with the same Idempotency-Key uses order budget like a new order.
Test and production are metered separately, because a test key and a live key are different keys. The per-account order budget applies to production only.

When you are over a budget

Code	Status	Meaning
`rate_limited`	429	The key’s read or order budget, or for production orders the account’s order budget, is used up.
`auth_throttled`	429	Too many failed authentications came from your address. Until it cools down, calls from that address are refused even with a good key.
`rate_limiter_unavailable`	503	Order metering is temporarily unavailable, so orders are refused rather than sent unmetered. Reads keep working.

429 Too Many Requests

{
  "detail": {
    "code": "rate_limited",
    "message": "API rate limit exceeded for this key or account. Retry later."
  }
}

Every 429 carries Retry-After: the number of whole seconds to wait. The API sends no other rate-limit headers, so do not wait for a remaining-count header.

Backing off

On 429 or 503, wait Retry-After seconds (or, without the header, a few seconds with jitter).
Retry an order with the same Idempotency-Key and body, so a retry can never book twice. See Idempotency and safe retries.
On auth_throttled, fix the key first: retrying a bad key keeps the address locked out.

Spread work out instead of bursting. A program that places many orders at once should pace them to stay under the 10-second budget, and poll pending orders every 1 to 2 seconds rather than in a tight loop.

Get started

Authentication

Core concepts

Guides

SDKs

Resources

Budgets

When you are over a budget

Backing off

​Budgets

​When you are over a budget

​Backing off

Budgets

When you are over a budget

Backing off