- WebSocketTransport
- ~2s pushCadence
- Crypto /
marketSubscribe by - Paid tiersAccess
Resolved Markets is, at its core, a historical order-book archive for backtesting and research. But for the markets that are live right now, the WebSocket feed is a convenient way to keep the current book in front of you, pushed on a steady cadence so you do not have to poll. Connect, authenticate, subscribe, and let it come to you.
A streaming feed flips the model. Instead of asking "what does the book look like now?" on a timer, you open one connection and the server pushes the current state of the live book to you. The feed broadcasts roughly every two seconds, which is plenty for dashboards and most alerting, it is a steady heartbeat of the current book, not a tick-by-tick event firehose.
The deep value is the archive
The WebSocket only serves markets that are currently active, once a market resolves, it lives on in the historical store, not the stream. So treat streaming as a live convenience layer; the backtesting and research depth comes from the snapshot history, which is where most of the work happens.
The connection flow
- 1Open a connection to the orderbook WebSocket endpoint.
- 2Authenticate by sending your API key in an auth message, no key in the URL.
- 3Subscribe to what you want, by crypto or by specific market.
- 4Receive the current book on each broadcast and react: update a UI, evaluate a rule, or refresh a signal.
When to stream, poll, or query history
Stream for live dashboards
A steady ~2-second push of the current book is ideal for a live UI or channel alerts on active markets.
- One persistent connection
- No polling loop
- Active markets only
Poll for simple checks
The live orderbook REST endpoint returns the same current book on demand, simplest for occasional reads.
- Stateless requests
- Easy to build
- Good for one-offs
Query history for depth
Anything analytical, backtests, studies, replays, runs against the stored snapshots, not the stream.
- Resolved markets too
- Full time ranges
- The core dataset
Auth happens after you connect
The feed authenticates with a message containing your API key, not a key embedded in the URL, so your credential does not leak into logs or browser history. Connections that do not authenticate in time are closed automatically.
What each broadcast carries
A broadcast is the current state of the book for a subscribed market, not a diff you have to replay. That keeps the client simple: you do not maintain an event log or reconstruct depth from deltas, you read the latest book and act on it.
- best_bid, best_ask, mid_price, spread, the derived prices, ready to render or threshold on.
- bid_depth_total and ask_depth_total, pre-summed depth for liquidity and imbalance reads.
- The bid and ask ladders for the market, for a full live depth view.
- crypto_price, the spot reference on crypto markets, so the odds sit next to where the asset is.
Connection limits by tier
- FreeNo WebSocket, REST only
- Pro1 connection
- Scale5 connections
- Enterprise10 connections
Each connection can subscribe to multiple markets, so the limit is rarely a constraint for a single dashboard. Plan one connection per process and fan subscriptions out from there, rather than opening a socket per market.
A heartbeat, not a firehose
The ~2-second cadence is a deliberate design choice: it is steady enough for live dashboards and rule-based alerting, and light enough to run reliably. It is not a tick-by-tick event stream, so anything sub-second or HFT-style is out of scope, and any deep historical analysis belongs to the snapshot archive anyway.
Stream the present, query the past. The WebSocket keeps the live book in front of you; the archive is where the research actually happens.
Open a stream
The docs detail the subscribe protocol and message shapes; pricing shows which tiers include WebSocket connections.
Frequently asked questions
How do I authenticate to the WebSocket feed?
After connecting, send an auth message containing your API key, then wait for the ok response before subscribing. Keys are not passed in the URL, which keeps them out of logs. Connections that do not authenticate within the timeout window are closed.
How often does the WebSocket push updates?
The feed broadcasts the current order book on a steady cadence of roughly every two seconds, best bid/ask, mid, spread, and depth, for the markets you subscribe to. It is a reliable heartbeat of the live book for dashboards and alerting, not a tick-by-tick event stream, so it is not intended for sub-second or HFT-style use.
Does the WebSocket cover closed markets?
No. The live feed only serves markets that are currently active. Once a market resolves it leaves the stream and lives on in the historical snapshot archive, which is where backtesting, research, and replay all draw from. Use the REST snapshots endpoints for any closed or historical market.
Is WebSocket access included on the Free tier?
WebSocket streaming is a paid-tier feature, Pro includes one connection, Scale and Enterprise include more. The Free tier uses the REST endpoints, which cover both the live orderbook and the full historical archive.
Can one connection follow several markets?
Yes. A single connection can subscribe to multiple markets, by crypto or by specific market, so a typical dashboard runs comfortably inside one connection. Plan one socket per process and fan subscriptions out from it rather than opening a connection per market.