> ## Documentation Index > Fetch the complete documentation index at: https://docs.coinversa.ai/llms.txt > Use this file to discover all available pages before exploring further. # WebSocket plan limits > Websocket capacity by plan — concurrent connections per account, subscriptions per connection, which of the twenty-one feeds each tier includes, multi-wallet lists against the subscription cap, fair-use bandwidth — and how the connection cap is shared across your API keys. 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 | Plan | Connections per account | Subscriptions per connection | Feeds | Fair-use bandwidth per month | | ---------- | ----------------------: | ---------------------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------: | | Free | 1 | 2 | `tradesByCoin`, `tradesByUser`, `candle`, `twapSliceFillsByUser` | 5 GB | | Starter | 1 | 25 | Free's feeds plus `trades` (the firehose), `tradesByUsers`, `allCandles`, `twapSliceFills` and `twapSliceFillsByUsers` | 50 GB | | Pro | 5 | 100 | all 21, including the `l4Book` [order book](/websocket/order-book), [liquidations](/websocket/feeds#liquidations), [leverage changes](/websocket/feeds#leverage-and-margin), [TWAP orders](/websocket/feeds#twap-orders), [TWAP statuses](/websocket/feeds#twap-statuses) and the [multi-wallet variants](/websocket/feeds#multi-wallet-subscriptions) | 250 GB | | Enterprise | custom | custom | all 21 | 250 GB | 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](/pricing#faq). * **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](/websocket/feeds#multi-wallet-subscriptions) 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](/websocket/order-book#when-a-book-subscription-is-dropped). A Pro trial account has Pro's websocket limits for the length of the trial. ## Resolved limits, not the table The [`connected` frame](/websocket/overview#the-first-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](https://developers.coinversa.ai/usage). ## 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](https://developers.coinversa.ai/usage). 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](/websocket/order-book#the-client-rule) — pays the snapshot again each time. The [TWAP status snapshot](/websocket/feeds#the-snapshot-on-subscribe) 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 | Limit | How it shows up | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Connection cap | The upgrade is refused: `HTTP 429` for header clients, close code `4429` for browser clients. No `Retry-After`; a connection that died silently frees its slot within about 40 seconds. | | Subscription cap | `{"channel":"error","data":"too many subscriptions"}` on the open socket. Unsubscribe one and the slot frees immediately. | | Order-book cap | None of its own: `l4Book` subscriptions spend slots from the general per-connection cap. | | Feed not in plan | `{"channel":"error","data":"feed not in tier"}` on the open socket — `trades`, `tradesByUsers`, `allCandles`, `twapSliceFills` and `twapSliceFillsByUsers` below Starter, and `l4Book`, `liquidations`, `liquidationsByUser`, `liquidationsByUsers`, `leverageUpdates`, `leverageUpdatesByUser`, `leverageUpdatesByUsers`, `twapOrders`, `twapOrdersByUser`, `twapOrdersByUsers`, `twapStatuses` and `twapStatusesByUser` below Pro. | | Wallets in one list | `{"channel":"error","data":"too many values for argument users"}` — over 1,000 distinct wallets on one `…ByUsers` subscription. Nothing is subscribed. Duplicates are removed before the count. | | Fair-use bandwidth | Nothing on the wire. The Usage page shows consumption against the allowance. | See the [wire protocol](/websocket/protocol#errors-on-an-open-socket) for the full error list and the [overview](/websocket/overview#when-the-handshake-is-refused) for refusals. ## Watching your usage The portal's [Usage page](https://developers.coinversa.ai/usage) 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.