{/* Metadata lives in ./layout.tsx */}

# 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. {{ className: 'lead' }}

---

## 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

1. Prefer batching orders (up to 250) over one-by-one.
2. On 429, wait `Retry-After` then resume. Natural keys make resume-anywhere safe.
3. Exponential backoff (2s / 4s / 8s) is fine for transport errors; for 429, prefer the server-provided delay.