Rate Limits

Overview

Rate limits protect the system from abuse while allowing legitimate trading activity. There are different limits based on client type and endpoint category.

Client Types

• Market Maker: High-frequency traders with whitelisted IPs, accessing dedicated private endpoints
• Normal User: Standard users accessing public endpoints via website or mobile app

REST API Limits

Important Notes

• Rate limits are enforced as average requests over time
• Exceeding limits results in HTTP 429 (Too Many Requests) responses
• Average requests per second (rps) are maintained over a 60-second window for order operations
• Peak rates allow burst operations within a 10-second window
• Create Order: All order creation endpoints count towards this limit
• Cancel Order: All order cancellation endpoints count towards this limit

WebSocket Limits

WebSocket connections have the following limits per IP:

Rate Limit Headers

When approaching rate limits, check response headers for:

• X-RateLimit-Limit: Maximum requests allowed
• X-RateLimit-Remaining: Requests remaining in current window
• X-RateLimit-Reset: Unix timestamp when the limit resets

Best Practices

1. Implement exponential backoff when receiving 429 responses
2. Batch operations where possible (e.g., bulk cancel instead of individual cancels)
3. Use WebSocket for real-time updates instead of polling REST endpoints
4. Cache responses for data that doesn't change frequently (products, assets)

Special Requirements

If you have trading requirements that exceed standard limits, please contact us. Rate limits are designed to prevent abuse, not to limit legitimate usage.