Skip to main content
Your plan sets how many subscriptions and connections you can hold and how fast a standard replay can run. Size your subscriptions, replay jobs, and consumer to fit inside it. For REST request rates, credits, and the full plan table, see Rate limits.

​
Limits by plan

Subscriptions are the most channel-symbol pairs one connection can hold. Connections are the most open WebSocket connections per account. Standard replay speed is the fastest speed a standard timed replay accepts. A higher request runs at your plan’s maximum. Every tier, including Free, has WebSocket access to every channel, including the L3 and L4 channels, except one: the live mempool channel, which comes with the Pro, Scale and Enterprise plans. Otherwise, plans set capacity and history windows; which channels exist depends on the venue family, as listed in WebSocket channels. Free replay reaches the most recent rolling 30 days, with a maximum 30-day window per replay. Build and above keep the full retained archive. Each connection accepts at most 10 subscribe or unsubscribe operations per second. A faster burst is refused with Subscription rate limit exceeded. Please slow down., so pace subscribe loops instead of sending a whole symbol list at once. Live Lighter and Lighter on Robinhood Chain subscriptions count toward the same plan limits as every other live channel, and so does each mempool subscription, unfiltered or per symbol. HIP-4 live WebSocket delivery covers trades and L4; use REST for current L2 and open interest, while stored L2 and open-interest history remains replayable. Core L4 checkpoint-anchored bulk replay is available on every tier. It is a replay format, not bulk WebSocket streaming: the stream command has been discontinued, and large dataset downloads use the Data Catalog Parquet export. Core L4 bulk replay ignores speed; its limit is the requested window and how fast your client processes checkpoint and batch messages.

​
What drives stream load

Start with one symbol and one channel, then widen only after the consumer keeps up without dropping messages.

​
Size a client

1

Start with one channel

Confirm connection, auth, message handling, gap handling, and unsubscribe with one channel-symbol pair.
2

Keep subscriptions explicit

Subscribe only to the channels and symbols the job needs, and track them so a reconnect neither duplicates nor loses a subscription.
3

Bound replay windows

Split long replays into windows you can resume and audit.
4

Avoid reconnect storms

Reconnect with capped backoff and jitter.
5

Measure consumer lag

Watch queue depth, processing time, and dropped UI updates before adding channels.
6

Track gaps

Treat gap messages as data-quality events and decide whether the downstream job can continue.
Whether you write the client yourself or an assistant generates it, do not default to the maximum subscriptions or the maximum standard replay speed. Name the channel set, symbols, delivery model, output destination, gap tolerance, and stop condition first, and run a bounded sample.

​
Backpressure

Protect the client from message bursts. Use bounded queues, drop or pause noncritical UI updates when necessary, and stop a replay rather than letting memory grow without limit. A replay that cannot be consumed in order is not a trustworthy replay, and a client that receives data faster than it can process it produces stale UI state, dropped messages, or incorrect local books. Track standard replay speed separately from live subscription count: live subscriptions stress steady-state processing, while replay stresses backlog, ordering, storage, and gap handling. Track core L4 by window and batch volume instead of speed. Check consumer lag before raising either one. A higher plan limit does not fix a consumer that drops messages or cannot write replay output in order. If one job mixes REST preflights, WebSocket replay, and SDK reconstruction, budget them together as one job, and run the Data quality checks before you share the tooling.

​
Next step

Choose the channels for your job in WebSocket channels.
Last modified on October 8, 2026