WebSocket tier limits

WebSocket tier limits are stream-specific capacity guidance: subscription count, replay speed, concurrency, message volume, and reconnection behavior. WebSocket limits depend on the plan envelope, channel mix, symbol count, replay speed, 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 replay speed	Max connections	Bulk streaming	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, and L3 / L4 channels are available on every tier. Higher tiers raise subscription caps, lift replay-speed budgets, and add bulk streaming (Pro and up). Channel availability is per venue, not uniform: trades and L2 order books on every venue, 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; see WebSocket channels for the full matrix.

Stream Limit Dimensions

Dimension	What to watch
Subscription count	Number of active channel-symbol pairs
Replay speed	How fast 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 replay speed. It should ask for the channel set, symbol set, 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 speed	Requested speed, replay window size, 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.

​Per-Tier Limits

​Stream Limit Dimensions

​Design Rules

​Plan Interaction

​Agent Review Rule

​Capacity Checklist

​Next Step