Skip to main content
Rate limits are implementation constraints, not just plan table rows. Use Rate limits and credits for the public plan table and this page for the design concept behind those limits. Rate limits are not only a number of requests per second. They are the combined envelope of request rate, concurrent queries, credit budget, WebSocket subscriptions, replay speed, retry behavior, and downstream processing capacity. Every plan reaches the same markets, routes, schemas, and depths; plans differ in capacity rather than archive access.

​
Limit Types

​
Client Pattern

1

Start narrow

Confirm one venue family, one symbol, one route, and one small window.
2

Separate heavy and light work

Do not let L3, L4, replay, or long-history jobs share an unbounded worker pool with freshness checks.
3

Back off with context

Preserve meta.request_id, route, symbol, retry count, and wait time when handling 429 or transient failures.
4

Store job shape

Save route family, symbols, windows, concurrency, and output destination so usage can be audited.

​
Automation Guardrails

Scripts should not default to every symbol, every channel, or every historical window. A safe job names the route family and symbol scope, sets a limit, implements backoff, logs request IDs, and writes output incrementally. For broad exports, start with a bounded sample request before widening the run. For WebSocket clients, rate limits interact with processing speed. A client that receives data faster than it can process will create stale dashboards, bad local books, or dropped replay messages even if the server accepts the subscription.

​
Limit Checklist

Before increasing scope, store the limit checklist with the job.

​
Next Step

Use Limits and throughput for implementation details, WebSocket limits for stream-specific sizing, and Credits for capacity planning.
Last modified on August 10, 2026