Rate limits

Two token buckets per key, and how to back off.

Limits are per key, not per IP or per account. Two independent token buckets:

Bucket	Covers	Sustained	Burst
Read	every GET	100/s	200
Write	orders, cancels, every mutation	50/s	100

A bucket that starts full can emit burst + sustained requests inside one second, so a read client can briefly reach 300 before throttling.

Batch order placement charges one token per order in the batch, not one per request — a 20-order batch costs 20 write tokens.

When you exceed a bucket

You get HTTP 429 with rate_limited, and the response body carries retry_after_ms in details:

{
  "error": {
    "code": "rate_limited",
    "origin": "gateway",
    "details": { "retry_after_ms": 220 }
  }
}

Back off for that long and retry. A 429 is a soft throttle with no penalty — you are not penalised for hitting it, and the next window is clean.

retry_after_ms is in the response body, not in a Retry-After header. HTTP client libraries that back off automatically on Retry-After will not see it — read it from the body yourself.

A 429 is not a suspension

Worth separating two different kinds of “no”:

• 429 rate_limited — a throttle. Back off, carry on.
• Suspension — a risk-management action against your account. Orders are refused until it is lifted. This is not something you retry your way out of.

If writes start failing with something other than 429, stop and read the error code rather than retrying harder.

Staying under

• Poll market data on an interval rather than in a tight loop. Rounds last 60 seconds; polling faster than a few times a second gains you nothing. Use the WebSocket for anything latency-sensitive.
• Batch order operations where you can — fewer requests, same token cost.
• Use one key per process. Two processes sharing a key share its buckets.

Higher limits

Per-key overrides exist. If you have a market-making use case that needs more than the defaults, get in touch rather than sharding across keys.