Execution Feed
Fills are pushed here for resting limit orders: a
GTC/GTD order that fills later, or one that is
marketable and fills as it is placed. An IOC/FAK/FOK order that fills immediately is not sent on
this stream; its fill comes back in the POST /v1/orders response. Treat that response (or GET /v1/orders)
as the record for immediate orders.Connection
Messages
Order Filled
This is the polysim-native fill frame. If you run a Polymarket-ported
bot, the same fills also surface as PM-shape
trade frames on the
/ws/user channel — see
PM-compat WebSocket.
Use whichever matches your existing event handlers; don’t subscribe to both
for the same fills.Reconnect without missing fills
Fills made by the background matching engine reach every API worker, so the socket you hold receives your fills wherever they were matched. Connections still drop (deploys, network, the 60-second token on reconnect), so treat the feed as at-least-once with replay:- Remember the last
order_idyou processed. - Reconnect with a fresh token (
POST /v1/keys/ws-token; tokens last 60 s) and pass that ID aswatermark:after_id=<id>andlast_event_id=fill_<id>are accepted aliases. The server first replays up to 50 fills newer than the watermark, then streams live ones. - De-duplicate on
event_id. A fill can arrive live and again in a replay. - Reconcile through REST once after each reconnect. Use one
GET /v1/orders?status=PENDING, because the feed carries fills only (no cancels or expiries), and a gap with more than 50 fills is not fully replayed.
GET /v1/orders/{id} for fills. See
Safe Order Polling Contract
for the request budget that polling would otherwise spend.
Example: Limit Order + Fill Listener
Next Steps
- WebSocket Overview — Authentication and protocol
- Price Feed — Real-time price streaming