;
};
Reference documentation for WebSocket connection limits, request limits, timeout behavior, and error codes.
Rate limit: `1000` WebSocket connections per minute and `200` JSON-RPC requests per minute per connection.
## Connection limits
| Scope | Limit |
| ----------------------- | ---------------- |
| New connections | 1,000 per minute |
| Requests per connection | 200 per minute |
Limit WebSocket connection creation to `1000` connections per minute.
Limit JSON-RPC requests to `200` requests per minute per connection.
Reuse a single WebSocket connection for multiple subscriptions. Opening a new connection per channel consumes the connection limit and increases latency.
## Subscription limits
| Scope | Limit |
| ----------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Active subscriptions per connection | None |
| Markets per subscription request | None |
| Per-channel-type limits | None — the same `200` requests per minute limit applies uniformly across all public and private channels |
A single connection comfortably maintains subscriptions across `200` or more markets. Distributing markets across multiple connections is not required for high-market-count workloads.
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"id": 1,
"method": "lastprice_subscribe",
"params": ["BTC_USDT", "ETH_USDT", "SOL_USDT", "XRP_USDT"]
}
```
The request above counts as one message regardless of the number of markets in `params`.
Repeating a subscription replaces the previous one for the same channel. To track additional markets on an active channel, send a new subscribe request with the full target list — the server does not merge incremental subscribes.
## Rate limit handling
Implement request throttling on the client side.
Queue subscription requests instead of sending bursts of requests.
Apply exponential backoff with jitter after receiving error code `7`.
Reuse active connections instead of creating new connections.
### Rate limit error example
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"error": { "code": 7, "message": "too many requests" },
"result": null,
"id": 2269
}
```
## Connection timeout
The server closes the WebSocket connection after `60` seconds of inactivity. Inactivity means no messages sent by the client.
Send a `ping` request every `50` seconds to keep the connection alive:
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"id": 0,
"method": "ping",
"params": []
}
```
**Expected response:**
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"id": 0,
"result": "pong",
"error": null
}
```
**Code example:**
```javascript JavaScript theme={"theme":{"light":"github-light","dark":"github-dark"}}
const socket = new WebSocket("wss://api.whitebit.com/ws");
setInterval(() => {
if (socket.readyState === WebSocket.OPEN) {
socket.send(JSON.stringify({
id: 0,
method: "ping",
params: []
}));
}
}, 50000);
```
## Error codes
The server returns errors in the `error` field of a response message. The `error` object contains a `code` and a `message`.
| Code | Message |
| ---- | ---------------------- |
| `1` | invalid argument |
| `2` | internal error |
| `3` | service unavailable |
| `4` | method not found |
| `5` | service timeout |
| `6` | require authentication |
| `7` | too many requests |
The server returns code `6` when a client invokes a protected method — a private-channel subscription or a balance query, for example — without first calling `authorize` on the connection. Send an `authorize` request before any private-channel subscription. See [WebSocket Authentication](/websocket/authentication) for the authorization flow.
**Error response format:**
```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"id": 1,
"result": null,
"error": {
"code": 1,
"message": "invalid argument"
}
}
```
The server closes the WebSocket connection immediately if the client sends invalid JSON.
## Best practices
**Reuse connections**. Each subscription does not require a new connection. Subscribe to multiple channels on a single connection to stay within the `1,000` connections per minute limit.
**Implement reconnection logic**. Handle unexpected disconnections with exponential backoff (for example, wait `1s`, `2s`, `4s`, `8s` between retries). Re-subscribe to all channels and re-authorize private channels after reconnecting.
**Batch subscriptions**. Subscribe to all required channels immediately after connecting rather than one at a time. Batching reduces round-trips and avoids hitting the `200` requests per minute per connection limit during setup.
**Monitor ping latency**. A slow or missing `pong` response indicates network issues. Reconnect if the server does not return `pong` within `10` seconds after a `ping`.
## Related resources
* [WebSocket Overview](/websocket/overview) — Connection endpoint, message format, and quickstart.
* [WebSocket Authentication](/websocket/authentication) — Authorization flow for private channels.
* [REST API Rate Limits & Error Codes](/api-reference/rate-limits) — REST-specific limits and error formats.