Skip to main content
Each plan has a hard cap on concurrent WebSocket connections. Subscriptions per connection are a separate limit on the multiplexed endpoint.

​
One counter for every route

These upgrade paths share one Redis counter:
  • wss://therundown.io/api/v1/ws
  • wss://therundown.io/api/v2/ws (multiplexed)
  • wss://therundown.io/api/v2/ws/markets
  • wss://therundown.io/api/v2/ws/hedge
Super allows 3 concurrent connections on that counter. API keys on the same account share the allowance. The Redis key is ws_conn:api:user:{sha256(userID)}. A second key on that account does not add another 3 connections. A legacy API key with no user id is counted on its own, at ws_conn:{sha256(apiKey)}. Browser sessions use a separate identity and do not consume this API allowance. A clean close decrements the counter immediately. There is no reconnect grace window. An unclean disconnect or a half-open TCP session can hold the slot for up to 60 seconds, until peer liveness closes it.

​
What the 429 says

When the counter is already at the plan cap, the upgrade is rejected with HTTP 429:
limit is the plan cap. On Super it is 3. peer_liveness_seconds is 60. The rejected upgrade does not take a slot. Reconnecting while that dead session still holds the slot returns the same 429. Wait for peer liveness to close it, or close another live connection on the account, then connect again. The server also sends a JSON heartbeat and a WebSocket ping every 15 seconds. If the client stops answering, the server can close the connection and free the slot through that same 60 second peer-liveness timeout. See the WebSocket overview for channels, filters, and snapshots.