Skip to main content
Every plan, Free included, can call every route and subscribe to every WebSocket channel except one: the live mempool channel, which comes with the Pro, Scale and Enterprise plans. Otherwise, plans differ in capacity: how many requests you can send each second, how many can run at once, how many credits you can spend in a month, and how much WebSocket and replay capacity you get. Prices and checkout are on the pricing page.

​
Requests

What a request costs in credits is on Credits.

​
WebSocket and replay

Each connection accepts at most 10 subscribe or unsubscribe operations per second. WebSocket limits shows how to size a client to these numbers.

​
History

Free serves the most recent rolling 30 days, and one request or replay can span at most 30 days. Build and above keep the full retained archive, so the first served date of each dataset sets how far back a request can reach. Free tier has the rest of the Free plan.

​
Export credits and Webhook Alerts

Export credits reduce the cost of file exports, which are priced per order; see Exports. Unused export credits roll over, as Credits explains. The webhook allowance covers endpoints, rules, watched wallets and deliveries a day. Deliveries are counted per account across every endpoint and do not use API credits, and a rule that crosses the daily allowance pauses until you resume it; see Webhook Alerts.

​
When you reach a limit

Every metered REST response carries your current position in its headers: x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset for the per-second limit, and x-credits-limit, x-credits-used, x-credits-remaining and x-credits-reset for monthly credits. Reset values are Unix seconds. A 429 is not always worth retrying. Read its error_code, and the field beside it, before you decide:
  • Request rate: 429, error_code rate_limited, and retry_after, the seconds to wait. Wait that long, then retry at a lower request rate, within a fixed retry budget.
  • Concurrent queries: 429, error_code rate_limited, and max_concurrent, your plan’s limit. There is no wait value: retry when one of your in-flight requests finishes, within the same budget, and cap your worker pool at the limit.
  • Monthly API credits: 429, error_code insufficient_credits, with credits_used and credits_limit. Stop the job. A retry cannot succeed until credits reset at x-credits-reset or the plan changes.
  • Temporary unavailability: 503 with a Retry-After header. Wait that many seconds and retry within the budget.
  • WebSocket subscriptions: a subscribe beyond the plan’s limit gets an error message with error_code rate_limited. Unsubscribe from something first; a retry of the same subscribe fails the same way.
  • Mempool channel on Free or Build: a mempool subscribe gets an error message with error_code forbidden. A retry cannot succeed until the plan changes to Pro, Scale or Enterprise.
  • Standard replay speed: a replay that asks for more than the plan’s speed runs at the plan’s speed. Nothing to retry.
If a response you can retry carries no wait value, use capped exponential backoff with jitter and lower concurrency. Keep the request ID of every failed attempt: the top-level request_id in the error body, or the x-request-id header. Do not retry an authentication, malformed-request, unsupported-symbol or invalid-parameter error unchanged; fix the request first. Errors lists every status code and error_code.

​
Design clients around limits

Build clients as queues, not as unbounded loops. A historical job that knows its route, symbol, time window, page size, concurrency and retry budget before it starts can pause, resume and explain a run without duplicating data.
1

Start with one symbol and one route

One BTC order-book request confirms authentication and the response shape. One one-hour trade window confirms pagination, latency and the output schema.
2

Split long pulls into windows

Retry or resume each window on its own, from its saved cursor, so one failure does not restart the whole job.
3

Keep heavy and light work apart

Run L3, L4, replay and long-history jobs in their own bounded worker pool, so one slow request cannot block freshness checks.
4

Set stop conditions

Stop or pause on a rate-limit response that persists, a credit threshold, stale data, a gap event or consumer lag, and record why the run stopped.
For WebSocket clients, limits interact with processing speed. A client that receives data faster than it can process it produces stale dashboards, bad local books or dropped replay messages even when the server accepts every subscription.

​
Next step

Run one bounded job inside these limits with the Limits and throughput guide.
Last modified on October 8, 2026