The WebSocket API provides a powerful technology for establishing two-way interactive communication between users and the FastPath server.
It enables real-time sports betting and media data updates and eliminates the need for polling the server for responses. WebSockets utilize a bidirectional protocol, offering the fastest real-time data transmission for building real-time sports betting and media applications. The following message types require authentication, and data availability depends on the user's subscription license.
Messages sent and received via WebSockets are encoded in JSON format.
Decimal fields, including timestamps, are quoted to preserve precision.
At least one message should be subscribed to in order to maintain an authenticated client connection.
Use the Fixtures REST API endpoints to fetch the list of fixtures that can be subscribed via the WebSockets API. The 'id' field provides the supported fixture ID for subscription.
Our REST API and WebSocket endpoints are only tailored for B2B use. Using our data to connect directly with the DDE is prohibited. This helps ensure data integrity and security. If you have integration needs, we can discuss proceeding within our guidelines. Please feel free to reach out with any questions to support@openbet.com.
Authentication Refer to the Access Tokens documentation for detailed information.
Sequence Numbers FastPath feeds include sequence numbers ("fixtureSeqNum") in their messages. These numbers are monotonically increasing integers starting from 1 and operate on a per-connection and per-feed basis. They help clients identify if they are dropping messages, receiving messages out of order, or processing messages differently from the server's order.
Connection Status WebSockets enable real-time communication between clients and servers. However, disconnections can occur due to various reasons such as network issues, server unavailability, or client-side errors. The URL for the production environment is
wss://dde-streams.data.imgarena.com.
When a WebSocket connection is disconnected, sending and receiving messages from the server becomes impossible. To handle this, a mechanism is implemented to detect and manage disconnections. This includes using heartbeats to detect disconnections, implementing automatic reconnection, and displaying warning messages to the user.
If there are any connection issues with the data collection network, IMG sends connection status packets in WebSocket feeds to indicate that the upstream provider is not sending data. These packets do not contain sequence numbers. Here is a sample format of the expected status packet:
Connected
Disconnected
Valid state values are:
Connected
Disconnected
The Connected status is sent when a packet is received and the previous state was Disconnected. The status change is delivered before the packet.
The Disconnected status is sent if no packets (including heartbeats) have been received for a known feed. A feed is considered known if any data has been received from it, including heartbeats. The system checks for feed disconnection every 10 seconds and marks it as Disconnected if no data has been received within the last 30 seconds. We also added a lastConnectedTimestamp to the /actions websocket in May 2024 which will reference the last timestamp of an action (goal, card, subs, corner etc), or a heartbeat message prior to a disconnection. This will help users understand the time of the last packet during the period of connectivity. This will be tagged on the Disconnected ConnectionStateChangedmessages.
If a packet is received at 5 seconds and no further packets are received, the feed will be marked as disconnected at 40 seconds. This is the first 10-second interval in which at least 30 seconds have passed since receiving the packet.
Note that connection statuses are deduplicated to avoid sending redundant ConnectionStateChanged events unless the new state is different from the previous state.
During a suspension, the collection status is updated manually by the supervisor when the scorer goes offline. However, the scorer continues to collect data locally, which is sent to the server upon reconnection. Users will receive all missing actions upon the scorer's reconnection.
For more information on error handling, please refer to the documentation.