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.

​

Network Rate Limits

​

Authorization Endpoint Rate Limit

​

User Account API Rate Limit

All User Account API endpoints:

• Get Balances
• Get Open Orders
• Get Open Order by ID
• Get Completed Orders
• Get Positions
• Get Deposits
• Get Withdrawals
• Get Fundings

Currently, we don’t enforce rate limits on individual users for these User Account API endpoints, but 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.

​

WS Connection Limits

​

WebSocket Connection Rate Limit

​

Concurrent WebSocket Connection Limits

WebSocket connections are subject to concurrent connection limits that vary by user type and connection scope. These limits are shared between UI and API access and can be increased upon request.

​

Market Makers

Market-Specific Connections: Market-Agnostic Connections: The limit is calculated as: Per-market limit × Number of supported markets.

​

Retail/Institutional Users

If you exceed the concurrent connection limit, establishing additional connections returns 403 Forbidden.

​

Order Creation and Operation Rate Limits

​

Account-Level Rate Limit

The following WebSocket and REST API requests share a combined account-level rate limit across all markets, regardless of API keys:

​

Maximum Open Orders Per Market

To prevent abuse, Rails enforces strict limits on open orders per market: 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 maximum open orders count of 80 reached message
• 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 may lead to Order Creation Ban

​

Handling Rate Limit Violations

If you exceed any of the above rate limits, you will receive a 429 Too Many Requests response and you must back off and avoid sending further requests until the limit resets. The rate limit counter resets every minute based on the timing of your first request, not at fixed minute intervals. Note that User Account API Rate Limit is an exception that resets every second. 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 violating the Account-Level Rate Limit and/or failing to back off after receiving 429s will result in an automatic soft ban for 5 minutes and you will be disconnected. What happens during a rate limit soft ban:

• All Order Creation WebSocket connections are immediately disconnected across all markets
• New Order Creation WebSocket connections are blocked for 5 minutes
• Connection attempts return 403 Forbidden with 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 400s 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)
• All order creation requests are rejected with 403 Forbidden status
• The rejection includes a RetryAfterSec field indicating when you can try again
• 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 WebSocket and REST APIs. Implement rate limiting in your code to stay below your limit. 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 REST APIs.

​

WebSocket

• The apiQuotaUsed field is included in the 202 acknowledgement messages for both Create Order and Cancel Order requests. 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.

​

REST

• The Get Order By ID endpoint includes 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