> ## Documentation Index
> Fetch the complete documentation index at: https://docs.whitebit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# WebSocket Rate Limits & Error Codes

> Connection limits, request limits, timeout behavior, and error codes for the WhiteBIT WebSocket API.

Reference documentation for WebSocket connection limits, request limits, timeout behavior, and error codes.

<Warning>
  Rate limit: `1000` WebSocket connections per minute and `200` JSON-RPC requests per minute per connection.
</Warning>

## 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`.

<Note>
  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.
</Note>

## 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"
  }
}
```

<Note>
  The server closes the WebSocket connection immediately if the client sends invalid JSON.
</Note>

## 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.