API Rate Limit

Q1: What is the API Rate Limit?

Q2: What are the current primary rate limit rules?

• Order Placement Rate Limit: Applies to all order-related requests (e.g., place, modify, cancel).
  • Rule: Maximum of 2 requests per every 2 seconds.
  • Purpose: To prevent erroneous operations and market anomalies caused by excessively frequent ordering.
• General Request Rate Limit: Applies to all API requests (including market data queries, account inquiries, and order operations).
  • Rule: Maximum of 50 requests per every 10 seconds.
  • Purpose: To manage overall server load and protect system resources.

Q3: What happens if I send requests too quickly and exceed the limit?

• For order requests: The order will not be executed.
• For query requests: You will temporarily be unable to retrieve data. You must wait for the current time window to pass before sending valid requests again.

Q4: How is the request frequency calculated and managed?

• Sliding Time Window: The system does not reset counters at fixed intervals (e.g., at the start of every 2 or 10 seconds). Instead, it continuously checks the number of requests you have made in the immediately preceding 2-second or 10-second period. For example, for the order limit, you must not exceed 2 requests in any contiguous 2-second timeframe.
• Implement Client-Side Throttling: It is strongly recommended to build delays or use algorithms like a token bucket in your application code to control the request pace and avoid hitting the limits.
• Endpoints Share Limits: The order placement limit applies to all order-related endpoints. The general request limit applies to all API endpoints collectively.

Q5: What are the best practices to avoid hitting rate limits?

• Optimize Request Patterns: For non-critical, non-real-time data (e.g., account balance), reduce the query frequency (e.g., query once every 1-2 seconds instead of polling every millisecond).
• Utilize WebSocket Streams: For real-time market data, order book updates, and order state changes, we strongly recommend using our WebSocket streams. This is the most effective way to reduce the number of proactive HTTP requests and avoid hitting the general request limit.
• Batch Operations & Aggregate Queries: Where possible, use batch order or batch query endpoints to reduce the number of individual requests.
• Implement Retry Logic with Backoff: Add reasonable intervals between consecutive requests (e.g., at least 500ms between orders). If you receive a 429 error, your program should pause and retry after an exponentially increasing delay.