Rate limits
Per-key limits protect the platform without requiring client-side guesswork. When you hit one, the 429 tells you exactly how long to wait.
Limits
| Surface | Limit | Notes |
|---|---|---|
| Reads | 1,200 req/min / key | Metrics, connections, ingest status. MCP shares this budget: switching surfaces does not double it |
| Writes | 600 req/min / key | At 250 orders/batch, about a 150k orders/min ceiling |
| Collect | 120,000 events/min / token | Plus 600 events/min per IP. Over-limit events are dropped, the response stays 204 |
| Collect debug | 10 req/min / token | ?debug=1 verdicts, development only |
A 1M-order history backfills in roughly seven minutes without tripping 429, if the client respects the batch size.
Day-1 implementation is an in-process per-key window (approximate under horizontal scaling). Shared-state limiting is a scaling follow-up with the same numbers.
Headers
On 429:
| Header | Meaning |
|---|---|
Retry-After | Seconds to wait before retrying |
X-RateLimit-Limit | Budget for this window |
X-RateLimit-Remaining | Remaining requests (zero when limited) |
Client guidance
- Prefer batching orders (up to 250) over one-by-one.
- On 429, wait
Retry-Afterthen resume. Natural keys make resume-anywhere safe. - Exponential backoff (2s / 4s / 8s) is fine for transport errors; for 429, prefer the server-provided delay.