Rate limits
Limits keep the venue fast and fair for everyone. Design clients to back off gracefully and lean on the WebSocket for realtime data.
Default tiers
| Surface | Limit | Scope |
|---|---|---|
| Public reads (market data) | 60 / min | per IP |
| Authenticated reads | 120 / min | per key |
| Order placement / cancel | 300 / min | per key |
| WebSocket connections | 64 channels | per socket |
Indicative during the play-money phase
These are the fair-use targets clients should design against — they may tighten or relax as the platform matures. The hard cap enforced today is the per-socket WebSocket channel limit. If you're building a high-frequency strategy or market maker, get in touch about a higher tier.
When you hit a limit
Over-limit requests return 429 Too Many Requests. Back off and retry after a short delay — ideally with exponential backoff and jitter. Like all errors, the body is a flat { "error": string } envelope.
429 Too Many Requests
{
"error": "Too many requests. Slow down and retry shortly."
}Best practices
- Subscribe to the WebSocket for live order books and tickers instead of polling REST.
- Batch order placement and cancellation with the
/batchedendpoints (up to 20 per call). - Cache rarely-changing data like categories and series locally.
- Use
client_order_idfor idempotency so retries never double-submit.