Various Websocket Use Cases

Use these WebSocket patterns to confirm order status, monitor market updates, and manage risk in real time.

Order activation confirmation

Orders on ProphetX rely on FIFO queues for activation. After you submit an order through the REST API, record its order_id. You will receive a private-channel update indicating whether the order was activated successfully or failed. The most common failure reason is insufficient cash balance.

Safety protection

If you do not receive an order activation message within 10 seconds of submission, the cause may be a WebSocket disconnection or a lost message. Reconnect the WebSocket and call GET /v4/mm/get_order/{id} to retrieve the current order status.

Order cancellation confirmation

After you cancel an order through POST /v4/mm/cancel_order, or cancel multiple orders through POST /v4/mm/cancel_multiple_orders, a successful response returns 200. The canceled orders can no longer be filled. A private-channel update identifies the orders that were canceled. Attempting to cancel an order that is already canceled returns 400.

Build the order book in real time

To build the order book for a market and track fill activity, subscribe to market_selections on the broadcast channel. Call GET /v4/mm/get_markets or GET /v4/mm/get_multiple_markets every 15 minutes and compare the response with your WebSocket-built order book. This helps prevent inaccuracies caused by missed WebSocket messages.

To receive real-time fill details, bind trade_execution (or, on the legacy vocabulary, matched_bet) — not on the market_selections channel, but on the channel from a {"type": "tournament", ...} subscription, under whatever binding name your registration response lists for it (tournament_{id} and/or v2.tournament_{id}). See WebSocket Events for the exact binding names and payload shape.

Risk control in real time

Fill updates for your orders are pushed to you through a private channel. These messages include details such as order_id, filled_quantity, and fill_price. Use this information to rebalance your book and minimize exposure in real time.

Ensure WebSocket connectivity

A disconnect event is typically sent when the WebSocket connection is lost. To reduce false positives, you can also listen to the health_check message on your private user channel — it's not on a broadcast channel — sent every 5 seconds. If you rely on this message, disconnect and reconnect the WebSocket if no health_check message is received for more than 30 seconds.