PolyDataFeed.xyz

Polymarket · on-chain trade feed

Every trade,
in sequence.

A WebSocket feed of Polymarket trades as they land on Polygon — reassembled from raw fill events into whole trades, and numbered so you can prove for yourself that nothing went missing.

wss://feed.polydatafeed.xyz/ws example · slowed ~35×

A slowed-down example of real market data — the feed itself runs about 35× faster. Sequence, side, price, size in shares, makers.

What you receive

Whole trades, not log soup.

On-chain, a single Polymarket trade is scattered across several events: an OrdersMatched boundary, one fill per maker who took the other side, and a separate fee event. Read the chain naively and you get fragments you have to stitch together yourself, in the right order, while more arrive.

We do that reassembly and send you one JSON object per trade: the taker, every maker who filled against them, sizes, average and extreme prices, fees, and the block and transaction it came from.

  • TransportOne WebSocket, one JSON object per frame.
  • Contents21 fields per trade, plus a maker breakdown.
  • Volume15–30 per second on average, no ceiling.
  • CoverageBoth Polymarket exchange contracts.

Completeness

You don't have to trust us.

Every message carries a sequence number that increases by exactly one. If a trade never reached you, the number after the gap is two higher than the one before it, and your own code can see that without asking us anything.

That is the whole point. Most feeds ask you to take completeness on faith. This one hands you the means to check it, on every message, continuously.

If your client ever falls behind faster than we can send, you get an explicit client_lagged warning naming how many messages were dropped — rather than silence and a hole in your data.

The same principle covers our own downtime. The feed is live only: if it goes down, trades from that window are not captured and are not replayed afterwards. So the counter restarts at zero when the feed does, which tells you plainly that there was an outage and you may be missing that window. Resuming the count would look tidier and would hide exactly the thing you need to know.

gap detectionillustration
196784
BUY  0.870 × 5.00 sh
196785
SELL 0.990 × 0.02 sh
196787
← 196786 never arrived

Three lines of arithmetic in your client catch this. In our own measured runs the count is zero — but the point is that you can tell.

Latency

Single-digit milliseconds, and honest about the rest.

A trade is decoded, bundled and pushed in under a millisecond of server time. From our London server to a client in the Netherlands we measure around 8 ms one way — essentially all of it distance, not software.

Your own number depends on where you sit. We would rather tell you how we measured it than quote a figure you can't reproduce, so the method is in the docs and the test client is yours to run.

  • Server timeUnder 1 ms from ingest to emit.
  • Measured~8 ms one way, London → Amsterdam.
  • TransportTLS 1.3, heartbeat every 30 s.
  • ReconnectsOurs automatic. Yours a plain reconnect.

Access

Two weeks free, then we talk.

Tell us a little about what you're building and we'll issue you an API key with two weeks of full access — the same feed, no throttling, no reduced fields. Nothing to cancel: the key simply stops working when the fortnight is up unless you decide to continue.

We haven't published a price. Volumes and needs differ enough that we'd rather see how you use it and quote something that makes sense for you.

  • Trial14 days, full feed, one API key.
  • TurnaroundUsually same day — a person reads every request.
  • EndingThe key expires on its own. No card, nothing to cancel.
  • ContinuingWe extend the same key. Your integration doesn't change.