Delta Feed

Delta Feedchevron-right

Data Elements

  • Every event consists of 4 data elements. eventInfo - basic information about the event. markets - contains data about markets, selection and odds values. scoreboard - contains data about periods and score. betCancellations - contains data about the time period in which bets placed on specific markets should be cancelled.

  • Every data element has a dedicated delta type that is used to send updates for this specific element. Two exceptions are eventSnapshotDelta (type6), which contains all data elements, and eventStatusChangedDelta (type 1), which is used to update status and tradingStatus that are located inside eventInfo.

Data Storage Recommendations

  • Recommended approach of storing data for events is following. eventInfo should be stored in a document database like MongoDB. markets, scoreboard, betCancellation data is stored in a cache like Redis. This allows for time critical data of markets/odds to be processed and forwarded to frontend as fast as it is possible.

Establishing Connection

  • After receiving credentials from TIS, the next step is to establish connection with Odds88 websocket delta feed. Initial connection should happen with revision = 0 to get messages for all active events. After that you should connect with revision = version from latest delta received.

circle-exclamation

Storing Data

  • Subscribing with revision = 0 will generate snapshots (type 6 delta) for all events active in a Odds88 system. This type of delta contains full data about an event and includes all 4 data elements. If an event doesn’t exist in the your database, it should be created. If an event exists all data elements that changed should be updated.

  • Upon receiving delta of type 2 a new event should be created in your DB. If an event already exists, changed fields should be updated. Deltas of type 2 and 6 are the only two deltas that should create new events in your database.

  • Next step is to process every other delta type that contains only updates for already existing events and update changed fields/properties in the database/cache for further use in your system/frontend solution. Structure of all delta types can be checked in swagger.

  • Events can have from 0 to many markets.

  • Markets can have from 1 to many selections.

  • After message processing is implemented, you can populate your database by connecting to feed with 0 revision. In case of reconnection it should happen with revision = version from latest delta processed. Existing data should be enough to create frontend views of sports, leagues and events.

  • To process messages it is required to use a multithreaded solution. Number of messages and their size can be significant during peak hours for a single threaded solution to handle the volume.

  • It is recommended to use MongoDB + Redis, for quick and reliable forwarding of data to frontend.

Market settlements

Delta Feed delivers selection-level market settlements — i.e. the outcome of each individual selection in a market. This tells your system “what happened on the field” for a market, independent of any specific player’s bet. There is no dedicated settlement delta type. Settlement data is carried as a regular field on each selection inside the standard delta types that include market data. When a market is settled, the selection’s settlement field changes from 0 (None) to its final result.

Two delta types include selections, and therefore can carry settlement data: 6 - EventSnapshot 7 - MarketsChanged

The Delta Feed SettlementResult enum (used in SelectionViewModelV2.settlement):

Value
Name
Description

0

None

Not yet settled

1

Refund

Stake fully returned

2

Lose

Selection lost

3

Win

Selection won

4

HalfLose

Half stake lost (Asian handicap / quarter lines)

5

HalfWin

Half stake won (Asian handicap / quarter lines)

Examples:

Last updated