Rate limits and retries
Stay within per-key and account budgets, read response headers, and make safe retry decisions.
Limits apply across all requests using a key and across all keys on its account. Adding keys does not increase the account's total budget.
Default request budgets
The default window is 60 seconds. Deployments can configure different limits; use the values returned by the API and the key-management page.
| Budget | Default |
|---|---|
| Reads per customer key | 600 per window |
| Reads across all keys on an account | 1,200 per window |
| Trade writes per customer key | 60 per window |
| Trade writes across all keys on an account | 120 per window |
| Quote, order prepare, hosted order, and cancel prepare | 30 per minute on each route, in addition to key limits |
| Anonymous Market API reads, where enabled | 120 per IP per window |
Pre-authentication IP limits can also apply. Failed trade signature attempts count toward the write budget. When a deployment requires a key for market data, a rate allowance does not grant anonymous access.
GET /api/v1/me/api-keys returns the current key limits with a customer session. It is not itself an API-key-authenticated endpoint.
Read the headers
| Header | Purpose |
|---|---|
X-RateLimit-Limit | Limit reported for the request's applicable rate window. |
X-RateLimit-Remaining | Remaining requests in that window. |
X-RateLimit-Reset | Reset information for the current window. |
Retry-After | Whole seconds to wait after a 429 response. |
On HTTP 429, honor Retry-After before retrying. Slow the whole worker or shared queue using the affected credential, not just one request. Continue to respect any tighter route budget.
Retry by outcome
| Outcome | What to do |
|---|---|
429 | Wait for Retry-After, then retry with backoff and jitter. |
Temporary 5xx or a read timeout | Retry reads with a bounded backoff; retain the request ID when present. |
401 or 403 | Correct the credential, scope, signature, clock, IP restriction, or Party authorization first. |
| Validation failure | Correct the input. Repeating it unchanged will not help. |
| Expired quote or changed venue | Fetch and review a fresh quote. |
| Ambiguous result after an order write | Reconcile the existing command before starting a new operation. |
Set a maximum retry count or elapsed-time budget. A trading client must not keep retrying an expired quote or repeat a rejected order indefinitely.
Idempotency for orders
An Idempotency-Key identifies one logical write. Generate and persist it before sending the request, along with the exact payload. Reuse it for a retry of that same write. A different payload with the same key returns IDEMPOTENCY_KEY_CONFLICT.
Trade signatures have separate replay protection. A retry needs a new timestamp and signature even when its idempotency key and payload stay the same. See request signing.
Do not treat a network timeout as a failed order. The server may have accepted the request before the connection closed. If you have a commandId, check its status; otherwise retry the same idempotent write to recover its result.
Reduce avoidable traffic
- Use conditional reads with
ETagon market endpoints that support it. - Use the WebSocket stream for subscribed pairs instead of polling every pair continuously.
- Share cached public metadata across users when the response's cache policy permits it.
- Page through bounded responses; do not restart full-history reads on every refresh.
- Coordinate the account's rate budget across processes and keys.