Rate Limits

Rate limits are designed to protect the platform and its participants. Please design around these rate limits to avoid getting soft banned or banned from the platform.

​

WS Connection Limits

​

WebSocket Connection Rate Limit

​

Concurrent WebSocket Connection Limits

WebSocket connections are subject to a limit on how many you may hold open at the same time. Connections scoped to a single market count against that market’s allowance; connections that are not scoped to a market are counted separately. These limits are shared between UI and API access, are configured per account, and can be increased upon request. If you exceed the concurrent connection limit, establishing additional connections returns 403 Forbidden.

​

Order Creation and Operation Rate Limits

​

Account-Level Rate Limit

Requests are metered per account across all markets, regardless of API keys. Each class of operation has its own budget, so exhausting one does not throttle the others. Every request costs one unit from its class’s budget, single-order cancellation included. Only the bulk Cancel Orders REST endpoint is not budgeted, so a caller that has spent its cancellation budget can still clear its book. A reduceOnly order — a create with reduceOnly: true, or a modification of a resting reduceOnly order — draws on a separate reduce-only allowance instead of the creation or modification budget. That allowance is unlimited unless one is configured for your account, and a reduceOnly order is never refused by the Order Creation Ban. Short-burst limits apply on top of the per-minute figures, so send requests at a steady rate rather than spending a class’s whole minute allowance at once. Where the table says configured per account, the allowance is set for your account rather than fixed platform-wide. Contact our support team if you need one raised.

​

Maximum Open Orders Per Market

To prevent abuse, Rails enforces strict limits on open orders per market: These are the defaults; like the concurrent-connection allowance, they are configured per account. Important details:

• All orders regardless of status (active, pending, cancelling, modifying) count toward this limit
• Applies to both limit and market orders (including IOC orders) combined
• Exceeding this limit results in order rejection with 400 Bad Request and error code CREATE_ORDER_MAX_OPEN_ORDERS (1004) (see the Order Creation Stream reference for error details)
• Use Get Open Orders to monitor your current count

Implications:

• Hitting the limit often indicates submission rates are higher than allowed
• Reduce submission rate to avoid throttling and pending/cancelling backlogs
• Repeatedly violating this limit and/or failing to back off after receiving 400 Bad Request may lead to Order Creation Ban

​

Handling Rate Limit Violations

If you exceed any of the above request rate limits (the open-orders cap answers with 400 as described above), you will receive a 429 Too Many Requests response with error code TOO_MANY_REQUESTS (0003) and you must back off and avoid sending further requests until you have room in that budget again. Wait for the period given by the Retry-After header or the retryAfterSec field; room returns gradually rather than all at once. Note that User Account API Rate Limit is a separate, per-second control. If you have special requirements or expect high traffic, please contact our support team for assistance.

​

Soft Ban

To protect our core order creation and cancellation services, we implement a “soft ban” mechanism for both Account-Level Rate Limit and Maximum Open Orders Per Market violations. There are two different types of soft ban behavior depending on the violation:

​

Rate Limit Soft Ban (Disconnection)

Repeatedly having order creation, modification or cancellation requests refused, and failing to back off after receiving 429s, will result in an automatic soft ban for 5 minutes and you will be disconnected. A refused read or account-settings request does not lead to a disconnection. What happens during a rate limit soft ban:

• All Order Creation Stream WebSocket connections are immediately disconnected across all markets
• New Order Creation Stream WebSocket connections are blocked for 5 minutes
• Connection attempts return 403 Forbidden with error code SOFT_BANNED (0011) and message user soft banned till ${unix timestamp}

​

Order Creation Ban (Cancellation Only)

Repeatedly violating the Maximum Open Orders Per Market limit and/or failing to back off after receiving 400 Bad Request will result in an order creation ban, but you will remain connected to the WebSocket. What happens during an order creation ban:

• You remain connected to the WebSocket (no disconnection)
• Order creation and modification requests are rejected with 403 Forbidden status and error code CREATE_ORDER_BANNED (1005), except a reduceOnly create or a modification of a resting reduceOnly order
• The rejection includes a retryAfterSec field indicating when you can try again (see the Order Creation Stream reference for error details)
• Other WebSocket operations (like order cancellation) continue to work normally

​

Avoiding Soft Bans

• For Account-Level Rate Limit (prevents disconnection): See Monitoring Rate Limit Usage for how to monitor your current usage in both the WebSocket and HTTP APIs. Implement rate limiting in your code to stay below your limit, metering each operation class separately. In case you receive 429 responses, immediately back off and wait based on the retryAfterSec field or the Retry-After header before sending further requests.
• For Maximum Open Orders Per Market (prevents order creation ban): Keep track of the number of all open orders (not just active ones, but also pending and cancelling ones) you have in each market using Get Open Orders endpoint. If you approach the limit, please check if you have any open orders stuck in pending or cancelling status before creating new orders. If so, please reduce the order creation rate in this market until the total number of open orders goes down to around the normal number of orders you intend to create in the order book.

​

Monitoring Rate Limit Usage

You can monitor your Account-Level Rate Limit usage in both the WebSocket and HTTP APIs.

​

WebSocket

• The apiQuotaUsed field is included in the 202 acknowledgment messages for both Create Order and Cancel Order By ID requests on the Order Creation Stream. This indicates your current request count toward the account-level rate limit.
• The retryAfterSec field is included in the 429 rejection messages when you exceed the rate limit, telling you how long to wait before retrying.

​

HTTP

• The order read endpoints — Get Order By ID, Get Open Orders, and Get Completed Orders — include headers that expose your current usage and quota:

  Header Name	Description	Always Present
  X-Api-Quota-Used	Requests made in the current rate limit window	Yes
  X-Api-Quota-Limit	Current rate limit (requests per minute)	Yes
  Retry-After	Seconds to wait before next request (present on 429 responses)	No

​

Network Rate Limits

​

User Account API Rate Limit

All User Account API endpoints:

• Get Balances
• Get Positions
• Get Deposits
• Get Withdrawals
• Get Fundings

These endpoints are rate limited per individual account, in the Account reads and Ledger reads classes listed under Account-Level Rate Limit. In addition, there are API-level rate limits shared by all users: These limits are applied globally across all users and should be more than enough for normal usage.