Skip to main content
WebSocket limits depend on your plan, channel mix, replay speed, and the amount of data a symbol emits.

​
Client Rules

1

Keep subscriptions explicit

Subscribe only to the channels and symbols the job needs.
2

Bound replay windows

Split long replays into windows that can be resumed and audited.
3

Avoid reconnect storms

Use capped backoff and jitter after disconnects.
4

Track gaps

Treat gap messages as data-quality events and decide whether the downstream job can continue.

Rate limits

REST and account-level limit model.

Reliability guide

Handle data gaps and freshness checks.

​
Sizing A Stream

A stream’s effective cost is a function of symbol count, channel count, venue activity, replay speed, and downstream processing. Start with one symbol and one channel, then widen only after the consumer can keep up without message drops. If a replay job is meant to produce research output, record the window, speed, channel list, and gap events with the resulting file.

​
Limit Review Checklist

Use this checklist before increasing channel count, replay speed, or connection count.
FieldCapture
ModeLive subscription, replay, L4 reconstruction, dashboard stream, alert, or backtest
Venue familyHyperliquid core, Spot, HIP-3, HIP-4, or Lighter
Channel setExact channel-symbol pairs or replay channel list
Account envelopePlan, subscription count, replay speed, credit budget, and concurrent replay behavior
Consumer capacityQueue depth, processing lag, dropped UI updates, output write rate, and memory ceiling
Recovery policyRetry budget, reconnect backoff, resubscribe list, gap response, and rebuild path
Stop triggerLag threshold, gap state, storage failure, auth failure, or data-quality failure
The checklist keeps a limit request tied to the client that has to consume the messages. A higher plan limit does not fix a consumer that drops messages or cannot write replay output in order.

​
Backpressure

Clients should protect themselves from message bursts. Use bounded queues, drop or pause noncritical UI updates when necessary, and stop replay rather than letting memory grow without limit. A replay that cannot be consumed in order is not a trustworthy replay.

​
Plan Interaction

Account limits can affect both REST and WebSocket use. If a workflow mixes REST preflights, WebSocket replay, and SDK reconstruction, budget them as one job instead of independent scripts. Pair this page with Rate limits and Data quality before deploying shared tooling.

​
Review Rule

Before raising subscription count or replay speed, verify consumer lag. A WebSocket job that receives data faster than it can process produces stale UI state, dropped messages, or incorrect local books. Document limit decisions near the consumer, not hidden in a connection helper. Track replay speed separately from live subscription count: live subscriptions stress steady-state processing, while replay stresses backlog, ordering, storage, and gap handling. Size and observe them independently.
Last modified on June 28, 2026