Skip to main content
polynode’s WebSocket is the fastest way to get Polymarket trade data. Every fill is delivered 3-5 seconds before on-chain confirmation (1-2 blocks early). Subscribe to 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.
Save ~60% bandwidth with compression. Add &compress=zlib to your connection URL and decompress binary frames with standard inflateRaw. Zero latency impact, recommended for production. See compression docs →

Quick start

1

Get an API key

Save the pn_live_... key from the response.
2

Stream trades (30 seconds)

Save this as stream.js and run with API_KEY=pn_live_... node stream.js:
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.
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.
If you need the full transaction format with nested fills and status lifecycle, subscribe to settlements instead:
See Settlement Event for the full field reference.

Connection URL

With compression (~60% bandwidth savings):
The API key is passed as a query parameter. Keys starting with 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}
If no heartbeat arrives within ~35 seconds, the connection is dead — reconnect. The server monitors client liveness via incoming messages and Pong frames. If no activity is received from the client within 5 minutes, the server closes the connection with a close frame explaining the reason. Standard WebSocket clients handle Pong automatically, which counts as activity.

Application-level keepalive

Send a ping message to confirm the connection is alive:
Response:
Any message you send (subscribe, unsubscribe, ping) resets the server’s liveness timer.
Running behind a reverse proxy (Railway, Render, Heroku, AWS ALB, etc.)? Some cloud platform proxies intercept WebSocket Ping/Pong control frames at the proxy layer and don’t forward them to your application. This means the server never receives your client’s automatic Pong responses, and the connection gets dropped for inactivity.The fix: Send {"action": "ping"} every 30-60 seconds from your application code. These are regular text frames that pass through any proxy. This is the recommended keepalive method for any containerized or cloud-hosted deployment.

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 the since filter to fill any gaps:
The 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.