Exchange Websocket

The WebSocket API delivers real-time order book updates, trades, candles, engine status, and account events (orders, fills, positions, balances, liquidations). It is the recommended path for any latency-sensitive integration.

Connecting

Browsers cannot attach custom auth headers to a WebSocket upgrade, so authentication uses a short-lived token rather than a header:

1. Call POST /ws-tokens over HMAC (a normal signed REST request). This mints a 60-second, single-use opaque token. Your HMAC secret never crosses the WebSocket boundary.
2. Open a WebSocket to the /stream endpoint and present the token to subscribe.

Tokens are single-use and reaped after 60 seconds; mint a fresh one per connection.

Connection limits

• Maximum 5 active connections per IP. A 6th connection is rejected (or the oldest is evicted).
• Rate limits and tiers are shared with the REST API — see Rate & Connection Limits.

Channels

Subscriptions are per-market where noted. Available channels:

Channel	Scope	Payload
book	per market	Order book depth updates
trades	per market	Executed trades
candles	per market	OHLCV candles
engine	global	Engine throughput and status
orders	account	Order lifecycle updates
fills	account	Your executed fills
positions	account	Position changes
balances	account	Balance changes
liquidations	account	Liquidation events

Account-scoped channels (orders, fills, positions, balances, liquidations) require an authenticated subscription tied to your token.

Delivery targets

The system targets low-latency fan-out; published latency goals tighten across release gates (order-book and fill delivery measured from the matching event to client receipt). Current testnet behavior is suitable for development and integration testing.

Status: testnet preview. Exact subscription message framing and per-channel schemas are defined in the OpenAPI spec at /openapi.json and the live API reference at exchange.nexus.xyz; use those as the authoritative source for message shapes.