Skip to main content
The orderbook stream lives at a single endpoint:
Authentication happens during the WebSocket upgrade — there is no separate login message and no token to refresh mid-stream. You either open the connection authenticated, or the upgrade is rejected before the socket opens.

One key for REST and the stream

The stream authenticates with the same signed API key you use for the REST API — an Ed25519 keypair whose public half is registered to your actor. There is no separate stream credential. You sign the handshake with your private key exactly the way you sign a REST request; the private key never leaves your side.

Signing the handshake

Because a browser cannot set custom headers on a WebSocket upgrade, the signed credentials ride the query string: The canonical string is the REST canonical with the method literal WS, the sorted query excluding keyId/timestamp/signature, and the empty-body hash:
Signing it with the WS method means a handshake signature can never be replayed against a REST request on the same path, and vice versa. Signing it is a few lines with the standard library — the same Ed25519 signature you produce for REST, over this canonical string:
(The empty middle line is the sorted query with the credential params removed — empty here because the orderbook endpoint takes no other query parameters.)
Keep your timestamp in unix seconds and synced to the server clock (see GET /v1/time); a signature outside the ±30s window is rejected. A signature authorizes only this exact handshake and expires with its timestamp window, so a leaked URL stops working within seconds rather than being a durable credential — but the private key that produced it is the real secret: guard it, and never put it in a URL.

Handshake responses

The outcome of authentication is an HTTP status on the upgrade request, before any frame is sent: Once the upgrade succeeds the server immediately sends a welcome frame. From there, see Subscriptions & markets to start streaming.