Rate Limits
Per-account and per-IP throttling, response headers, and 429 handling.
To ensure fair usage and protect the API, requests are subject to per-account (or per-IP for unauthenticated requests) rate limits.
Default limit
All authenticated endpoints share a default bucket:
| Scope | Limit |
|---|---|
| Per account | 1000 req / minute |
| Per IP (unauth) | 1000 req / minute |
Stricter per-endpoint limits
Sensitive or resource-intensive endpoints have additional, lower limits that run on top of the default bucket:
| Endpoint | Method | Limit | Scope |
|---|---|---|---|
/v2/auth/nonce | GET | 20 / min | per IP |
/v2/auth/verify | POST | 10 / min | per IP |
/v2/orders | POST | 300 / min | per account |
/v2/orders/batch | POST | 100 / min | per account |
/v2/positions/close | POST | 300 / min | per account |
/v2/withdraw | POST | 5 / min | per account |
/v2/transfers/internal | POST | 10 / min | per account |
/v2/deposit/signature | POST | 10 / min | per account |
/v2/referral/claim | POST | 5 / min | per user |
Response headers
Every response includes:
| Header | Meaning |
|---|---|
x-ratelimit-limit | Max requests in the current window |
x-ratelimit-remaining | Remaining requests in the current window |
x-ratelimit-reset | Seconds until the window resets |
retry-after (on 429) | Seconds to wait before retrying |
When you hit a limit
The API returns HTTP 429 Too Many Requests with:
Headers:
retry-after: 60
x-ratelimit-limit: 5
x-ratelimit-remaining: 0
x-ratelimit-reset: 60Body:
{
"ok": false,
"error": "Rate limit exceeded, retry in 1 minute",
"errorId": "180f0dc0be29c0a8"
}Use the retry-after header (seconds) to know when to retry. The errorId
can be quoted in support requests.
Best practices
- Read
x-ratelimit-remainingand slow down before hitting 0 - Back off using
retry-afterrather than retrying immediately - Batch order operations via
/v2/orders/batchwhen placing many orders - Cache static reference data (markets, instruments) on your side
Cap your client-side rate to ~80% of the published limit. Bursts and clock skew between client and server make hard-pinning the limit unreliable.
High frequency
If your usage will sustainably exceed these limits, contact the operations team about the volume tier / market-maker programme. Higher limits are granted manually today.