WebSocket tier limits

WebSocket tier limits are stream-specific capacity guidance: subscription count, standard replay speed, concurrency, message volume, and reconnection behavior. Core L4 bulk replay ignores speed; its capacity boundary is the requested window and the client’s ability to process checkpoint and batch messages. 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.

Lighter live subscriptions are available on lighter_orderbook, lighter_trades, lighter_open_interest, and lighter_funding through wss://api.0xarchive.io/ws. lighter_candles and lighter_l3_orderbook are replay-only, and all six Lighter channels support historical replay. Live Lighter subscriptions count toward the same plan limits as other live channels.Lighter on Robinhood Chain live subscriptions are available on rh_lighter_orderbook, rh_lighter_trades, rh_lighter_open_interest, and rh_lighter_funding through wss://api.0xarchive.io/ws. rh_lighter_candles is replay-only, and all five Robinhood Chain channels support historical replay. They count toward the same plan limits.

WebSocket limits depend on the plan envelope, channel mix, symbol count, replay delivery model, data family, and client processing capacity. A client can be inside account limits and still produce bad output if it cannot consume messages in order.

Per-Tier Limits

Tier	Max subscriptions	Max standard replay speed	Max connections	L3 / L4 channels
Free	10	10×	2	✓
Build	500	50×	3	✓
Pro	3,000	100×	5	✓
Scale	20,000	300×	16	✓
Enterprise	Unlimited	from 500×	Unlimited	✓

Every tier, including Free, has WebSocket access. The table describes capacity, not universal route access. Published route access is not sold as a higher-tier feature; plans govern capacity and request windows, while availability is route, family, symbol, and schema-specific. Higher tiers raise subscription caps and lift standard replay-speed budgets. 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. Channel availability is family-specific: trades and L2 order books on Hyperliquid core, Spot, HIP-3, HIP-4, and Lighter, plus candles on Lighter, liquidations on core and HIP-3, funding on core, HIP-3, and Lighter, and open interest on core, HIP-4, and Lighter. Lighter order books, trades, open interest, and funding stream live, all six Lighter channels support historical WebSocket replay, and current Lighter candles and L3 depth use REST. 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. See WebSocket channels for the route matrix.

Stream Limit Dimensions

Dimension	What to watch
Subscription count	Number of active channel-symbol pairs
Standard replay speed	How fast standard historical events are emitted
Venue activity	Busy markets produce more messages
Data depth	L3 and L4 workflows are heavier than simple status checks
Consumer lag	Local queue depth and message processing delay
Reconnect behavior	Duplicate subscriptions or reconnect storms
Output storage	Whether replay output can be written fast enough

Design Rules

Start with one channel

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

Track active subscriptions

Store channel and symbol state so reconnects do not duplicate or lose subscriptions.

Measure consumer lag

Watch queue depth, processing time, and dropped UI updates before increasing channel count.

Separate live and replay budgets

Live subscriptions stress steady-state processing. Replay stresses backlog, ordering, storage, and recovery.

Plan Interaction

Use Rate limits for current public plan envelopes and account-specific terms. Then design WebSocket clients as bounded consumers. The plan may allow a number of subscriptions, but your application still needs to process messages, rebuild after gaps, and avoid reconnect storms. If the workflow mixes REST preflights, WebSocket subscriptions, replay jobs, and SDK reconstruction, budget them as one product workflow. Do not size WebSocket in isolation from the data-quality and recovery calls that make the stream trustworthy.

Agent Review Rule

Generated WebSocket code should not default to maximum subscriptions or maximum standard replay speed. It should ask for the channel set, symbol set, delivery model, output destination, gap tolerance, and stop condition. If those are missing, generate a bounded sample instead of a broad run.

Capacity Checklist

Use this checklist before raising stream limits or asking for a larger plan.

Field	Capture
Channel-symbol count	Active subscriptions and planned maximum
Replay delivery	Requested standard speed when applicable, replay window size, batch volume for core L4, and output destination
Consumer capacity	Queue depth, processing time, storage write rate, and dropped-message behavior
Recovery behavior	Reconnect cap, resubscribe list, gap policy, and rebuild path
Related calls	REST preflights, data-quality checks, SDK reconstruction, and export writes
Stop condition	Lag threshold, retry budget, storage failure, or data-quality failure

Next Step

Use WebSocket limits for client rules and Rate limits for account-level plan details.

Connect

Stream

Replay

Webhooks

WebSocket tier limits

Per-Tier Limits

Stream Limit Dimensions

Design Rules

Plan Interaction

Agent Review Rule

Capacity Checklist

Next Step

​Per-Tier Limits

​Stream Limit Dimensions

​Design Rules

​Plan Interaction

​Agent Review Rule

​Capacity Checklist

​Next Step

Per-Tier Limits

Stream Limit Dimensions

Design Rules

Plan Interaction

Agent Review Rule

Capacity Checklist

Next Step