fills to get one clean event per trade, or settlements for the full transaction lifecycle.
Fills
Individual trades, one per message. Pre-confirmation, flat format, no array parsing. The fastest way to track trades.
Settlements
Full transaction bundles with all fills in a
trades[] array plus status lifecycle tracking.Trades
Confirmed on-chain fills. Same data as settlements but after block confirmation with exact receipt values.
Combos
Pending Polymarket combo trades, order hashes, decoded legs, and receipt confirmations.
Up to 5 second edge
Settlements and fills detected before on-chain confirmation. Typically 3-5 seconds (1-2 blocks) early.
Filtered subscriptions
Subscribe by wallet, token, market slug, side, size, or event type. Only receive what you need.
Enriched events
Standard market events include title, outcome, slug, and image. Combo legs always include structural IDs; their cached
market details are optional.Crypto price feeds
Real-time prices for BTC, ETH, SOL, BNB, XRP, DOGE, and HYPE (~1/second each). Subscribe with
"type": "chainlink" on the same connection.Oracle resolution stream
UMA Optimistic Oracle events: market resolutions, disputes, proposals, and admin actions. Subscribe with
"type": "oracle" to track the full resolution lifecycle.Quick start
1
Get an API key
pn_live_... key from the response.2
Stream trades (30 seconds)
Save this as You’ll see individual trades streaming in, one per line. Each event is a single fill with clear fields for outcome, side, price, shares, and the wallet involved.
stream.js and run with API_KEY=pn_live_... node stream.js:3
What you'll see
Every message is one flat event with everything you need. Here’s a real captured fill:
block_number: null means this was detected before the block confirmed. Pre-confirmation delivery, 3-5 seconds ahead of on-chain settlement. One event per fill, no arrays to iterate, all fields included.fills vs settlements — both stream the same trades at the same speed. fills gives you one flat event per trade (simplest). settlements gives you the full transaction bundle with a trades[] array and lifecycle tracking via status_update events. Start with fills, move to settlements when you need the full lifecycle. See Subscriptions for all options.Settlement-based quick start (full lifecycle)
Settlement-based quick start (full lifecycle)
If you need the full transaction format with nested fills and status lifecycle, subscribe to See Settlement Event for the full field reference.
settlements instead:Connection URL
pn_live_ or qm_live_ are accepted.
Connection limits
Most apps only need one Event WebSocket connection. A single connection can carry multiple filtered subscriptions at once, including fills, settlements, trades, blocks, wallet filters, market filters, oracle events, and Chainlink price feeds.Event WebSocket limits apply to
ws.polynode.dev. Orderbook WebSocket limits for ob.polynode.dev are listed separately in the Orderbook Stream docs.Successfully delivered settlements, status updates, trades, redemptions, oracle events, and related event payloads appear under On-chain events in your usage dashboard. Compression reduces counted transfer because the meter uses the encoded payload delivered to the connection. Heartbeats, acknowledgements, control frames, and failed sends do not count. See Monthly usage allowances.
Multiple streams, one connection
PolyNode supports multiple subscription types on the same WebSocket:
All can run simultaneously on the same connection. See Subscriptions & Filters for full details on each type, including default event types and available filters.
Heartbeat
The server sends a heartbeat every 30 seconds:- A WebSocket-level Ping frame (handled automatically by WS clients)
- A text message:
{"type": "heartbeat", "ts": 1772386305181}
Application-level keepalive
Send a ping message to confirm the connection is alive:Connection lifecycle
Error handling
Invalid messages return structured errors:Reconnection
PolyNode does not send a close frame before disconnecting. Implement reconnection with exponential backoff and use thesince filter to fill any gaps:
since filter returns all events after that timestamp within your tier’s lookback window (free: 30s, starter: 2min, growth/enterprise: 5min). When since is set, it overrides snapshot_count. For outages longer than your lookback window, use the REST API to backfill.
