This document describes the currently active rate limiting rules for the v5 API (paths starting with /api/v5), to help you plan your request rate and avoid being throttled.
The quota values below reflect the current production configuration and may change with operational policy. Always rely on the usage returned in the response headers, and watch for official announcements.
1. Rate Limiting Dimensions
Requests are rate limited across two dimensions. Both apply simultaneously; exceeding either one causes the request to be rejected:
- IP dimension: counted by the request's source IP.
- User dimension (UID): counted by your account. Applies only to private (signature-authenticated) endpoints.
Therefore:
- Public endpoints (e.g. market data, server time): limited by the IP dimension only.
- Private endpoints (authenticated endpoints such as placing orders, querying orders, querying balances): limited by both the IP and the user dimensions.
2. Current Quotas
We measure usage using a weight + time window model: each endpoint consumes a certain weight per call, and once the accumulated weight within a time window exceeds the total quota, requests are throttled.
Current quotas (window = 1 minute):
| Dimension | Total quota per minute |
|---|---|
| IP | 1800 weight |
| User (UID) | 1800 weight |
Current per-endpoint weight:
Each v5 endpoint currently consumes 1 weight per call. Under the current configuration this means:
- IP dimension: up to about 1800 requests per minute per IP (across all v5 endpoints under that IP, including public endpoints).
- User dimension: up to about 1800 private-endpoint requests per minute per account (across all private endpoints of that account).
Conversion: requests per minute ≈ total quota ÷ endpoint weight. Since the weight is currently 1, this is about 1800. If the weight of certain high-cost endpoints (e.g. placing or batch-placing orders) is increased later, the allowed request count for those endpoints will drop accordingly — always rely on the actual usage returned in the response headers.
3. Checking Your Usage
After each successful request, the response headers report the weight already consumed within the current time window, so you can monitor usage and adjust your pace in real time:
| Response header | Meaning |
|---|---|
X-SAPI-USED-IP-WEIGHT-1M | Weight consumed by the current IP in the last 1-minute window |
X-SAPI-USED-UID-WEIGHT-1M | Weight consumed by the current account in the last 1-minute window |
Recommendation: read these headers on the client side and slow down proactively as the used weight approaches 1800, rather than waiting to be rejected before retrying.
4. Responses When Rate Limited
When a rate limit is triggered, you will receive one of the following responses:
| HTTP status | Meaning | Recommended handling |
|---|---|---|
| 429 | Too many requests; the current request has been throttled | Reduce your request rate and retry after waiting per Retry-After |
| 418 | Temporarily banned due to repeatedly triggering the rate limit in a short period | Stop sending requests and resume only after the ban is lifted |
Both responses include a Retry-After header (in seconds) indicating the suggested wait time. For a 418 ban, the error message also includes the exact unban time (UTC).
Current ban rule: triggering the rate limit (429) a cumulative 50 times within 1 minute results in a temporary ban of 60 seconds; during the ban all requests return 418.
Always respect
Retry-After: continuing to retry at high frequency after a 429 will rapidly accumulate trigger counts and escalate to a 418 ban.
5. Best Practices
- Control your rate and keep headroom: keep the per-IP / per-account request rate below 1800 per minute, and leave a safety margin for bursts.
- Prefer batch endpoints: when submitting multiple orders, using the batch order endpoint is more efficient and consumes less quota than placing orders one by one in a loop.
- Avoid unnecessary polling: set reasonable polling intervals for query endpoints to avoid burning quota on idle polling.
- Monitor usage via response headers: watch
X-SAPI-USED-IP-WEIGHT-1M/X-SAPI-USED-UID-WEIGHT-1Mand slow down as they approach 1800. - Handle throttling responses correctly: implement exponential backoff for 429 / 418 and strictly respect
Retry-After; never retry immediately without a delay. - Plan IPs and accounts sensibly: avoid having multiple high-frequency accounts share the same egress IP — they share a single IP quota (1800/minute) and will compete with each other. If you need a higher quota, please request it through official channels.
6. FAQ
Q: How many requests per minute can I actually make?
A: Each endpoint currently has a weight of 1, so about 1800 per minute per IP and about 1800 per minute per account (private endpoints). Private endpoints consume both the IP and the account quotas at the same time.
Q: Why am I being throttled even though I'm not sending many requests?
A: Check whether other requests on the same IP or account are consuming the quota (for example, multiple programs or multiple accounts sharing one egress IP). You can confirm actual usage via the used-weight response headers.
Q: Are public endpoints rate limited too?
A: Yes. Public endpoints are limited by the IP dimension and share the 1800/minute quota with all other requests on that IP.
Q: How long until I recover after a 418?
A: The current ban duration is 60 seconds. Rely on the Retry-After (seconds) in the response and the unban time in the error message, and stop sending requests until then.