Rate-limit design

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, standard replay speed, retry behavior, request-window limits, and downstream processing capacity. Published market-data route access is not a higher-tier feature. Plans govern request rate, concurrency, credits, WebSocket scale, standard replay speed, export capacity, request-window limits, and Free’s rolling 30-day history window; actual availability remains route-, family-, symbol-, and schema-specific.

Limit types

Limit type	What it protects	Client design rule
Requests per second	API edge and account burst behavior	Queue work and back off on `429`
Concurrent queries	Heavy historical or long-running calls	Bound worker pools by route family
Credits	Volume and heavier data families	Estimate before broad loops
WebSocket subscriptions	Real-time stream fanout	Subscribe only to required channel-symbol pairs
Standard replay speed	Historical stream pressure	Bound windows, speed, and output storage
Archive coverage	Physical retained records by symbol and schema	Check symbol-level availability and freshness before production
Webhook deliveries	Daily delivery allowance per account, on plans that include webhooks	Size each rule with the estimate before enabling it; a rule that crosses the allowance pauses rather than dropping events

Client pattern

Start narrow

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

Separate heavy and light work

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

Back off with context

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

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.

Field	Capture
Scope	Route family, symbol set, data family, and time window
Capacity	Request rate, concurrent queries, credits, subscription count, or standard replay speed
Retry behavior	Backoff, jitter, max attempts, and status classes that stop the job
Trace	Request IDs, cursor state, output path, and data-quality decision
Stop condition	Rate response, credit threshold, stale data, gap event, or consumer lag

Next step

Use Limits and throughput for implementation details, WebSocket limits for stream-specific sizing, and Credits for capacity planning.

Get started

Plans & limits

Limit types

Client pattern

Automation guardrails

Limit checklist

Next step

​Limit types

​Client pattern

​Automation guardrails

​Limit checklist

​Next step

Limit types

Client pattern

Automation guardrails

Limit checklist

Next step