Skip to main content
Websocket access is capacity-based: you are limited by how many connections and concurrent subscriptions your plan allows and by a fair-use bandwidth allowance, never by how many messages you receive. Streaming does not draw down your REST request quota, and REST rate limits say nothing about it — the two are separate meters on the same key.

​
By plan

Two of these differ from REST limits in a way that bites:
  • The connection cap is per account, shared across every key. Five Pro connections are five in total, however many keys you spread them over. An indexer on one key, a staging box on another and a tab left open on a third are three of them. REST rate limits, by contrast, are per key.
  • The subscription cap is per connection. Each socket may hold that many distinct subscriptions; opening another connection (within the cap) gets you another set.
  • A multi-wallet list is one subscription. A …ByUsers subscription carrying 1,000 wallets spends one slot, not 1,000. The 1,000-wallet ceiling is the same on every plan; what differs between plans is how many such lists you may hold at once.
And one cap is specific to the order book:
  • l4Book subscriptions count against the subscription cap above like any other — there is no separate book-only limit. Going over is refused with too many subscriptions. Unsubscribing frees the slot immediately, and so does a book subscription that the server drops.
A Pro trial account has Pro’s websocket limits for the length of the trial.

​
Resolved limits, not the table

The connected frame reports what your account may do, with enterprise overrides already applied. Enterprise numbers are negotiated per account and can sit above or below the Pro row, so read the frame rather than this table when it matters. The same resolved numbers back the meters on the portal’s Usage page.

​
Fair use

Bandwidth is measured as the payload bytes of data frames written to your connections, rolled up per hour, and shown against your allowance on the Usage page. It is a soft cap: nothing is cut off at the line, and the counts are at-least-once analytics rather than a billing record. The firehose is where it goes — roughly a hundred and thirty fills a second across every market — so an indexer left running on trades is the case the allowance exists for. An order-book snapshot is a data frame written to your connection, so its bytes count too: about 30 MB for every subscribe to l4Book on BTC (about 15 MB on HYPE, 11 MB on ETH, and about 5 KB for the median coin), then the per-block diffs. A client that resubscribes on every reconnect — which is the correct behaviour — pays the snapshot again each time. The TWAP status snapshot is a data frame on the same terms, though it carries one entry per live TWAP rather than a whole book.

​
When you hit a limit

See the wire protocol for the full error list and the overview for refusals.

​
Watching your usage

The portal’s Usage page shows connections and subscriptions open right now against your caps — a snapshot the connection manager reports once a minute, so up to a minute old and hidden rather than guessed when no recent snapshot exists — plus bytes delivered against fair use, frames delivered, and connections opened over the period. “Connections opened” counts every successful connect, reconnects included; it is not how many are open.