Various Websocket Use Cases

ProphetX Service API — Various Websocket Use Cases

Play Activation Confirmation

Plays on ProphetX rely on FIFO queues for activation. After placing a play through the REST API, record the wager ID. You will shortly receive a confirmation message through a private channel indicating whether the play was activated successfully or failed. The most common failure reason is insufficient wallet balance.

Safety Protection

If you don’t receive a play activation message within 10 seconds of placement, it could be due to a WebSocket disconnection or a lost message. Please reconnect the WebSocket and call the REST API mm/get_wager/{wager_id} to retrieve the play status.

Play Cancellation Confirmation

After canceling a single wager or a batch of plays, a successful cancellation will return a 200 response, indicating the plays are canceled and cannot be matched anymore. A confirmation message will also be sent through the private WebSocket channel, including details on which plays were canceled. Attempting to cancel an already canceled play will result in a 400 error.

Order Book Real-Time Construction

To construct the order book of a market and track matching activities, subscribe to the message market_selection on the broadcast channel. We recommend calling the REST APIs mm/get_markets or mm/get_multiple_markets once every 15 minutes to compare with your WebSocket-constructed order book. This helps prevent inaccuracies caused by missed WebSocket messages. You can also subscribe to matched_bet topic in the same broadcast channel to get real-time matching details. When market liquidity is updated, it could mean a play was canceled or matched, and a matched_bet message, including odds and amount matched, will be sent through the broadcast channel if it is caused by matching.

Risk Control in Real-Time

Matching updates for your plays are pushed to you through a private channel. These messages include details like wager ID, amount matched, and matched odds. Your system can use this information to rebalance your own book and minimize exposure in real-time.

Ensure WebSocket Connectivity

A disconnect event is typically sent when the WebSocket connection is lost. To prevent false positives, you can also listen to the public message health_check, which broadcasts every 5 seconds. If you rely on this message, we recommend disconnecting and reconnecting the WebSocket if no health_check message is received for more than 30 seconds.