Rate Limits

The API is rate-limited to protect it from bursts and abuse. Limits are enforced globally across all servers, so they behave consistently no matter which instance serves a request.

The limits

Two windows apply to the Orders surface:

Both are fixed one-minute windows. Exact values are configurable and may be tuned; always read the response headers rather than hard-coding a number.

Response headers

Every response (not just 429s) carries the current budget:

On a 429, an additional Retry-After header tells you how long to wait.

Handling 429

When you exceed a limit you get 429 Too Many Requests in the standard error envelope with code RATE_LIMITED:

1
{ "error": { "code": "RATE_LIMITED", "message": "Rate limit exceeded.", "request_id": "req_01H..." } }

Back off and retry after the Retry-After interval. Best practice:

• Respect Retry-After; add jitter to avoid synchronized retries.
• Watch X-RateLimit-Remaining and slow down before you hit zero.
• Poll status on a relaxed cadence — it’s the most common source of avoidable request volume.