Skip to main content
Connect to wss://partner-api.bravadotrade.com/trade-feed/ws to receive a realtime stream of every trade across all markets; the rate varies with market activity — on the order of tens of trades per second (samples measured 20–50/s). On connect you get a snapshot of recent history, then a frame for every new fill. The feed is public, no API key or signature is required, and it is one-way: the server pushes to you, and any message you send is ignored.
Coverage today is Polymarket. The feed carries every trade on every market, not a selection of the active ones, and the rate varies with market activity — on the order of tens of trades per second (samples measured 20–50/s). Size your buffers and your UI for the whole hose, and filter client-side for the markets you care about. To follow a specific market’s book instead, use the Order Books feed.

Connect

Frames

Every message is a JSON object with a type field.

snapshot

Sent once, immediately on connect, so the feed does not start empty. It carries the last 200 trades as an array, newest first. The buffer is a fixed-count ring, not a time window. At the rates we have measured (20–50 trades per second) 200 trades is roughly four to ten seconds of history, and less than that when the market is busier — nowhere near thirty seconds, and not a fixed span you can rely on.

trade

Sent for every new fill after the snapshot.
The trade object in a trade frame and every element of the snapshot array share the same shape:
assetId links the two feeds. Watch the trade stream to discover which outcome tokens are active right now, then pass those IDs to the Order Books feed to see depth for them. And trader links Market Data to Trader Data: take a wallet you see filling and pull its PnL, positions, and history.

Keep-alive and reconnect

The server keeps the connection healthy with its own pings; you do not need to send heartbeats, and any frame you send is ignored. If the socket drops, reconnect and you will receive a fresh snapshot. Dedupe against trades already on screen using transactionHash, not id. id is built from a counter that lives in the serving process: it restarts from zero when the process does, and two instances give the same fill different ids. transactionHash identifies the fill itself.

Health

Returns whether the upstream source is connected, total trades emitted, recent-buffer size, and connected-client count.