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 utilise 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; 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 to maintain an authenticated client connection.
Use the Fixtures REST API endpoints to fetch the 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 talk about proceeding within our guidelines. Please don't hesitate 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 for 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 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:
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.
For example, 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.
Our WebSockets rely on rate limits to help provide a predictably pleasant experience for users.
This article overviews the rate limits you're likely to encounter for our features and then notes how the limitations apply to our live WebSockets.
We monitor customer traffic to ensure it follows guidelines and isn't excessive. We recommend a request rate of 5 per second and encourage staying connected to WebSocket instead of repeated re-connections.
Application credentials are required for production and simulation environments and cannot be shared publicly.
To utilise resources in your account, an access token from the support team is required. Obtain a Bearer authentication token by contacting the support team at support@openbet.com, necessary for connecting to the WebSocket endpoints.
We don't look at the header for websockets. Instead we expect the client to push through that auth message immediately on connecting in the following format:
It's important to keep your access tokens private, as they are meant to be secure and confidential.