Skip to main content
The stream pushes trades, candles and token updates as they happen. One WebSocket connection carries up to 100 subscriptions across every channel.

Connect

Open a WebSocket to wss://{{API_HOST}}/v1/stream, with your key in the Authorization header of the handshake.
The server checks the handshake before it upgrades the connection: A request without WebSocket upgrade headers gets a plain-text 4xx instead of an upgrade. Browsers cannot set the Authorization header on a WebSocket, so connect from your backend.

Frames

Every frame is a JSON text message.

From you

From the server

Subscription IDs

The server assigns each subscription a subscriptionId and returns it on the subscribe ack. Every update carries the ID of the subscription it belongs to. Use the ID to route updates in your client and to unsubscribe exactly. An unsubscribe without a subscriptionId closes every subscription you hold on that channel, and its ack carries no ID.

Ordering

  • A subscription’s ack always arrives before its first update.
  • An unsubscribe’s ack always arrives after that subscription’s last update.

Channels

Each channel’s reference page lists every filter, every update field and every error.

Errors

A refused frame gets an error frame. It uses the same codes as the REST API. An error about a subscribe frame echoes that frame’s id. A frame the server cannot parse, and a refused unsubscribe, get an error with no id. An error frame never closes the connection.

Keeping the connection alive

Send {"action": "ping"} every 30 seconds or so. If no pong arrives within a few seconds, treat the connection as dead and reconnect.

When the server closes the connection

Subscriptions do not survive a reconnect. After you reconnect, send your subscribe frames again. To fill the gap while you were away, read recent trades or candles from the REST API.

Reconnect loop

These loops resubscribe after every close, reconnect straight away after 1001, back off after anything else, and stop only on 401.