WebSocket Feeds
The PolySimulator API provides two shape families of WebSocket feeds for real-time data: a polysim-native shape (compact, condition-id keyed) and a Polymarket-compatible shape that mirrors Polymarket’s CLOB WS contract field-for-field so existing py-clob-client / PM-port bots can drop in without rewriting their event handlers.PolySim-native feeds
| Feed | Endpoint | Description |
|---|---|---|
| Price Feed | WS /v1/ws/prices | Real-time price updates for subscribed markets |
| Execution Feed | WS /v1/ws/executions | Limit order fill notifications |
Polymarket-compatible feeds (AF-14)
| Feed | Endpoint | Description |
|---|---|---|
| Market Channel | WS /v1/ws/market | Per-token L2 book + delta events (PM /ws/market shape) |
| User Channel | WS /v1/ws/user | Auth-gated user channel (PM /ws/user shape) |
- Accept PM’s subscribe message —
{"type": "market", "assets_ids": ["TOKEN_ID", ...]} - Emit PM-shape events —
book/price_change/last_trade_price/best_bid_ask, plus PM-shapetradefill frames on/ws/user(since 2026-06-11) - Field names match PM verbatim (
asset_id,market,hash,tick_size,timestamp, stringified prices) - Accept inline auth via the subscribe message —
"auth": {"apiKey": "ps_live_..."}(PM’s L2secret/passphrasefields are accepted but ignored — polysim is single-secret) - Also accept
?token=<jwt>for back-compat with the polysim-native auth model
Authentication
WebSocket connections require a short-lived JWT token (60 seconds), separate from your API key.Protocol
All messages are JSON. The protocol supports these client actions:| Action | Description |
|---|---|
subscribe | Subscribe to price updates for markets |
unsubscribe | Stop receiving updates for markets |
ping | Heartbeat check |
Ping/Pong
Connection Limits
| Tier | Max WS Connections | Max Subscriptions/Connection |
|---|---|---|
free | 1 | 50 markets |
pro | 3 | 50 markets |
pro_plus | 10 | 50 markets |
enterprise | 50 | 50 markets |
GET /v1/keys/tiers — the max_ws_connections field. The
Max Subscriptions/Connection value is fixed at 50 per connection
across all tiers (a hardcoded server cap, not tier-configurable and
not returned by /v1/keys/tiers).
Reconnection & Token Rotation
WebSocket tokens are short-lived — they expire after 60 seconds. They are not single-use: a token may be reused for multiple connections while it is still valid. The short TTL means most reconnect flows mint a fresh one anyway, so your bot must still implement automatic reconnection with token minting near expiry.Recommended Pattern
Key Rules
- Mint a fresh token near expiry — a token may be reused for multiple connections while still valid, but the 60-second TTL means most reconnect flows mint a new one anyway
- Re-subscribe after reconnect — the server does not remember your subscriptions
- Exponential backoff — start at 1s, cap at 30s, reset on successful connect
- Handle close code
4001immediately — no backoff needed, just mint and reconnect
Best Practices
Connect Immediately
WS tokens expire in 60 seconds. Mint and connect in the same code block.
Implement Reconnection
Use exponential backoff for reconnection. Mint a fresh token on each
reconnect attempt.
Prefer WS Over Polling
WebSocket subscriptions don’t count against REST rate limits.
Use them instead of polling
GET /v1/markets.Use Execution Feed
Subscribe to the execution feed for limit order fill confirmations
instead of polling
GET /v1/orders.Error Handling
| WS Close Code | Meaning |
|---|---|
4001 | Invalid or expired JWT token |
4002 | Maximum WebSocket connections exceeded |
4001, mint a fresh token and reconnect.
When you receive close code 4002, close idle connections before reconnecting.
Next Steps
- Price Feed — Subscribe to real-time prices
- Execution Feed — Get fill notifications