Feed integration
Replication Protocol
For reliable data delivery, a simple replication protocol is implemented. From an API point of view, it consists of two methods:
- get a
snapshot
for each sport event - get
log
stream where each log applies some change for specific sport event and it's entities
Snapshot
A snapshot is the current state of a sport event. A snapshot has a version
that sequentially progresses as the sport event changes. The version
is unique across all sport events and it always ascends. The object of a sport event consists of:
fixture
- all data on a sport event: status, type, sport, tournament, venue, links to streams, etc.markets
- the list of markets with outcomes, odds, and statusesbet_stop
- when it'strue
placing bets on this match is suspended at the momentcompetitors
- a list of participants with their scores (yellow/red cards, points, totals, etc.) in the matchgame_state
- contains all the game state (current period/time/ticker/server/quarter/round/etc. in the match, the number of properties depends on the type of sport) data available for the sport event.extensions
- describes additional extensions that could be attached to the sport event (e.g. see Widgets)
An example of a sport event snapshot
The output is formatted for readability, in the real response it will be a single line1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 |
|
Retention policy
A snapshot
of a sport event is retained for 5 days after the end of the sport event (after the sport event fixture has transit to one of the statuses: ended, closed, cancelled, abondoned). Once the retention period has expired, the snapshot
is no longer available.
Log
A log is a set of changes to a sport event. Every log has next fields:
version
- which corresponds to the version of the sport event snapshot at the time when the log was created. It means that the current version of the sport event snapshot is equal to the version of the latest log entry of the corresponding sport event.
sport_id
- ID of the sport (dota2, cs, etc.) sport_event_id
- ID of the sport event
timestamp_ns
- date (unix nano) of the sport event's update
event_type
- specify type of changes happened to the sport event
payload
- changes that occurred with the sport event
There are several event_type
, every type has its own structure (payload
field) and represent specific changes happened to the sport event.
Retention policy
A log
is retained for 3 days. Once the retention period has expired, the log
is no longer available. If you try to subscribe with a log version
that has already expired, the API will return a 409 HTTP code. It means that log with requested version is unavailable. If API returns 409 HTTP code for your latest processed log version it means that you must to resync all sport events by following steps from usage section.
sport_event_snapshot
It contains snapshot of the sport event. This event is received during initial synchronization for every sport event in a feed. After synchronization client receives messages that contain only partial updates of sport events (except sport_event_added
).
An example of log with `sport_event_snapshot` event type
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 |
|
sport_event_added
This event occurs when a new sport event has been booked or when a client refetches a sport event. It contains snapshot of the sport event.
An example of log with `sport_event_added` event type
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 |
|
This type of event has the same payload as sport_event_snapshot.
bet_stop_updated
This event occurs when status of the bet stop has changed during the match. If bet_stop
field is true
placing bets on this match must be suspended and markets should be locked on the UI until a bet stop
is deactivated (a log with bet_stop
equals false
is received). By default bet_stop
is deactivated (or in case of fetching sport event snapshot it equals SportEvent.bet_stop
).
Betstop Handling
Betstop is completely untied from market updates and must be handled separately. When betstop is true
, it's possible that some markets are being updated and even have active status, but bet placement must be stopped for the entire sport event until bet stop is moved to false
.
Alternative Integration
If your system doesn't support betstop functionality, you can request your DATA.BET integration manager to disable betstop events. In this case, you will receive markets_updated
events instead.
An example of log with `bet_stop_updated` event type
1 2 3 4 5 6 7 8 9 10 |
|
competitor_scores_updated
This event occurs when there is at least one score update for the competitor. It contains all the scores of all competitors.
An example of log with `competitor_scores_updated` event type
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
|
fixture_updated
This event occurs when at least one field of the fixture (match status, start date, amount of available streams, etc.) updated. It contains all fields of the fixture.
An example of log with `fixture_updated` event type
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
|
game_state_updated
Game state represent current state (current period/time/ticker/server/quarter/round/etc. in the match, the number of properties depends on the type of sport) of the sport event. This event occurs when at least on state property has an update. It contains all the game state data available for sport event.
An example of log with `game_state_updated` event type for soccer
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
markets_updated
This event occurs when at least one of the next events happened:
- markets statuses updated
- odds status updated
- odds values updated
- market has been added
Event contains only those markets that has updates (updated market contains all market fields including odds).
An example of log with `markets_updated` event type
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
|
extensions_updated
This event occurs when at least one of underlying extension has been updated
An example of log with `extensions_updated` event type for esports_counter_strike
1 2 3 4 5 6 7 8 9 10 11 12 |
|
bets_rollback
Critical Integration Requirement
This event is NOT related to risk management and MUST be integrated in ALL modes (including non-MTS risk management modes).
The bets_rollback
event instructs the client to roll back (void/refund) all bets on the specified markets that were placed within a specific time range [dt_start
, dt_end
] inclusive.
Key Differences from Other Events
bets_rollback
: Refunds bets placed within a specific time range only. Used when only certain bets need to be voided, not the entire market.markets_updated
with odd status 5 (refunded): Refunds ALL bets on a market regardless of when they were placed. Used when an entire market must be voided.
Important: Rolling Back All Bets
If the markets
field is an empty array, all bets associated with the given sport_event_id
must be rolled back. This ensures that no bets remain active when the rollback action is intended to apply to the entire event. The absence of specific markets
signifies that the rollback is not limited to particular markets.
These are possible reasons for the rollback:
1. 322
– The bet has been canceled due to suspicion of unfair play or match-fixing.
2. event_postponed_for_48_hours
– The event was postponed for more than 48 hours.
3. match_was_canceled
– The match did not take place as it was canceled.
4. competitor_is_incorrect
– There was an error in specifying the participants: the wrong competitor was listed.
5. partial_technical_lose
– The match ended partially due to technical reasons (e.g., one of the participants could not continue due to non-game-related circumstances).
6. technical_lose
– The match result was decided by a technical defeat (without full gameplay).
7. crash_of_the_game
– The game was interrupted due to technical issues (beyond our control), preventing the outcome from being determined.
8. after_goal
– The bet was placed after the decisive event (e.g. goal) had already occurred, making it invalid (commonly referred to as a "late bet").
9. technical_error_in_coefficient
– A technical error caused an incorrect coefficient to be specified in the bet.
10. pre_match_bets_after_match_start
– The pre-match bet was placed after the match had already started, making it invalid.
11. wrong_match_format
– The match format or conditions changed (e.g. football match had 40-minute halves instead of 45 minutes), resulting in partial refunds of the bets.
12. unplayed_market
– The selected market (bet event type) was not played or did not occur.
13. competitor_refusal
– One of the participants refused to participate, the match outcome was declared void.
14. duplicate_bet
– A duplicate bet was detected and canceled.
15. streamsniping
– The bet was canceled due to an unfair advantage (e.g. watching live streams in real-time).
16. product_ban
– The bets were refunded to users who were banned from our product.
17. marketing
– Bets were refunded for marketing accounts. These bets were placed for testing purposes.
18. competitor_has_been_replaced
- The competitor was changed in the match.
19. options
– This function was used when none of the predefined reasons applied.
An example of log with `bets_rollback` event type
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
heartbeat
Heartbeat is a message used to notify a consumer that a trading feed is alive. Recommended heartbeat interval is 5 seconds.
Actions required
If the client does not receive a heartbeat message or any other log event within 2 heartbeat intervals (10 seconds for the specified 5-second interval), the client must reconnect to the feed. This ensures the connection remains healthy and prevents data loss.
When MTS Risk Management is not applied
Heartbeat integration is required when MTS risk management is not applied. The client must stop accepting bets globally when no heartbeat messages or other logs are received within specified 2 heartbeat intervals to ensure proper connection monitoring and data integrity.
Heartbeats are sent every 5 seconds via RabbitMQ transport. For HTTP transport client specified heartbeat interval in seconds via query param heartbeat_interval
. Param is optional, if heartbeat_interval
is not specified heartbeat messages wil not be sent. For instance (client requests heartbeat message every 5 seconds):
1 2 3 4 5 |
|
An example of a message:
1 2 3 4 |
|
Received messages
1 2 3 4 5 6 7 8 9 10 11 |
|
Usage
We support 2 types of transport for sending logs: HTTP stream and RabbitMQ queue (experimental API).
Usage of HTTP stream API
The correct way to use the HTTP stream feed API is the following:
-
Request all snapshots via
GET /all
. In the response, the latest snapshot version will be indicated in theLast-Version
header, and the sport events themselves will appear in the body, each in a separate line. Chunked transfer encoding is used for streamingsport events
in HTTP 1.1 (if thesport event
does not fit in one line, it can be split into several lines (according to the encoding)).
Get a snapshot request via curl
`client.crt` and `client.key` will be provided by the DATA.BET integration team.The response:1 2 3 4 5
stdbuf -oL curl --request GET \ --url https://feed.int.databet.cloud/all \ --cert client.crt \ --key client.key \ --verbose \
1 2 3 4 5 6 7 8 9 10 11 12 13
... < Last-Version: 22hAUGMBUcD000004gfQzu < Last-Version-Hex: 17cd40f76bd7cd41000000010000b13e < Vary: Accept-Encoding < X-Api-Version: 2 < Date: Tue, 07 May 2024 20:00:42 GMT < Transfer-Encoding: chunked < 7576 {"sport_event_id":"1a70143e-159e-42d6-8645-97ad190a019f","sport_id":"football","version":"22h2KoCl1uu000004gfQS1","timestamp_ns":1715069754549926000,"event_type":"sport_event_snapshot","payload":{"fixture":{"type":0,"status":1,"streams":[],"sport_id":"football","template":"{$competitor1} vs {$competitor2}","tournament":{"id":"betting:17:gin:1c15e2ba-edbc-4776-a702-67eb835cd7c0","name":"U21. Premier League International Cup. Season 2023/2024"},"competitors":[{"id":"gin:a35f60db-0695-4f03-852f-e3d983346b16","name":"AD Confianca","side":"home","type":2,"template_position":1},{"id":"betting:7:sr:competitor:22431","name":"Ypiranga FC","side":"away","type":2,"template_position":2}],"live_coverage":false,"start_time_ns":0,"updated_at_ns":0},"markets":[{"id":"20","status":3,"odds":[{"id":"1","value":"1","is_active":false,"status":1},{"id":"2","value":"12.5","is_active":true,"status":2},{"id":"3","value":"100","is_active":true,"status":2}],"type_id":20,"specifiers":""},{"id":"201","status":3,"odds":[{"id":"1","value":"12.5","is_active":true,"status":2},{"id":"2","value":"1","is_active":false,"status":1}],"type_id":201,"specifiers":""},{"id":"589h1t1_5","status":3,"odds":[{"id":"1","value":"12.5","is_active":true,"status":2},{"id":"2","value":"1","is_active":false,"status":1}],"type_id":589,"specifiers":"halfnr=1&total=1.5"}],"bet_stop":false,"game_state":{"bo":1,"time":"541000","period":"period_1st_half","match_format":"live","period_number":1,"timer_running":true},"competitors_score":[{"scores":[{"id":"yellow_card","type":"yellow_card","number":0,"points":"0"},{"id":"red_card","type":"red_card","number":0,"points":"1"},{"id":"yellow_red_card","type":"yellow_red_card","number":0,"points":"0"},{"id":"total","type":"total","number":0,"points":"1"},{"id":"period_1st_half","type":"period_1st_half","number":0,"points":"1"}],"competitor_id":"gin:a35f60db-0695-4f03-852f-e3d983346b16","side":"home"},{"scores":[{"id":"total","type":"total","number":0,"points":"2"},{"id":"period_1st_half","type":"period_1st_half","number":0,"points":"2"},{"id":"yellow_card","type":"yellow_card","number":0,"points":"0"},{"id":"red_card","type":"red_card","number":0,"points":"3"},{"id":"yellow_red_card","type":"yellow_red_card","number":0,"points":"0"}],"competitor_id":"betting:7:sr:competitor:22431","side":"away"}]}} ... 9cd7 {"sport_event_id":"62b36a71-75d6-49a2-b72e-ca16bcde44f4","sport_id":"football","version":"33h2KoCl1uu111004gfQS1","timestamp_ns":1715069754549926000,"event_type":"sport_event_snapshot","payload":{"fixture":{"type":0,"status":1,"streams":[],"sport_id":"football","template":"{$competitor1} vs {$competitor2}","tournament":{"id":"betting:17:gin:1c15e2ba-edbc-4776-a702-67eb835cd7c0","name":"U21. Premier League International Cup. Season 2023/2024"},"competitors":[{"id":"betting:19:betting:1:sr:competitor:166150","name":"MSK Zilina","side":"home","type":2,"template_position":1},{"id":"betting:17:gin:361ba1ca-7c76-4fef-a703-2c7f8c2d9cdb","name":"TSC Backa Topola","side":"away","type":2,"template_position":2}],"live_coverage":false,"start_time_ns":0,"updated_at_ns":0},"markets":[{"id":"201","status":3,"odds":[{"id":"1","value":"12.5","is_active":true,"status":2},{"id":"2","value":"1","is_active":false,"status":1}],"type_id":201,"specifiers":""},{"id":"589h1t1_5","status":3,"odds":[{"id":"1","value":"12.5","is_active":true,"status":2},{"id":"2","value":"1","is_active":false,"status":1}],"type_id":589,"specifiers":"halfnr=1&total=1.5"}],"bet_stop":false,"game_state":{"bo":1,"time":"443000","period":"period_1st_half","match_format":"live","period_number":1,"timer_running":true},"competitors_score":[{"scores":[{"id":"yellow_card","type":"yellow_card","number":0,"points":"1"},{"id":"red_card","type":"red_card","number":0,"points":"1"},{"id":"yellow_red_card","type":"yellow_red_card","number":0,"points":"0"},{"id":"total","type":"total","number":0,"points":"2"},{"id":"period_1st_half","type":"period_1st_half","number":0,"points":"2"}],"competitor_id":"betting:19:betting:1:sr:competitor:166150","side":"home"},{"scores":[{"id":"total","type":"total","number":0,"points":"1"},{"id":"period_1st_half","type":"period_1st_half","number":0,"points":"2"},{"id":"yellow_card","type":"yellow_card","number":0,"points":"0"},{"id":"red_card","type":"red_card","number":0,"points":"0"},{"id":"yellow_red_card","type":"yellow_red_card","number":0,"points":"0"}],"competitor_id":"betting:17:gin:361ba1ca-7c76-4fef-a703-2c7f8c2d9cdb","side":"away"}]}}
-
Save the snapshots and
version
(Last-Version
header) from the previous response -
Subscribe to sport events updates using
GET /log
specifying the last savedversion
from step 1. The version value should be set in theLast-Version
header. In the response, the server will send a line-by-line log of sports event updates. Chunked transfer encoding is used for streaminglogs
in HTTP 1.1 (if thelog
does not fit in one line, it can be split into several lines (according to the encoding)).
Get a log request (curl)
`client.crt` and `client.key` will be provided by the DATA.BET integration team.The response:1 2 3 4 5 6
stdbuf -oL curl --request GET \ --url https://feed.int.databet.cloud/log?heartbeat_interval \ --cert client.crt \ --key client.key \ --header 'Last-Version: 22hAUGMBUcD000004gfQzu' \ --verbose
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
... < HTTP/1.1 200 OK < Cache-Control: no-cache, no-store, must-revalidate < Content-Type: text/event-stream; charset=utf-8 < X-Api-Version: 2 < Date: Tue, 07 May 2024 20:00:42 GMT < Transfer-Encoding: chunked < 8000 {"sport_event_id":"e5412aaa-bba5-4251-b027-00b61152486d","sport_id":"football","version":"22h9ySlp0fd000004gfR6m","timestamp_ns":1715096658000000000,"event_type":"fixture_updated","payload":{"type":0,"status":2,"streams":[],"sport_id":"football","template":"{$competitor1} vs {$competitor2}","tournament":{"id":"gin:653b9a71-92e9-4613-9b04-9c2e9c0d341e","name":"Brazil. Serie C"},"competitors":[{"id":"gin:a35f60db-0695-4f03-852f-e3d983346b16","name":"AD Confianca","side":"home","type":2,"template_position":1},{"id":"betting:7:sr:competitor:22431","name":"Ypiranga FC","side":"away","type":2,"template_position":2}],"live_coverage":false,"start_time_ns":1715095740000000000,"updated_at_ns":1715096658000000000}} 1d1 {"sport_event_id":"e5412aaa-bba5-4251-b027-00b61152486d","sport_id":"football","version":"22h9qfQK3pP000004gfFfy","timestamp_ns":1715096215000000000,"event_type":"competitor_scores_updated","payload":[{"scores":[{"id":"yellow_card","type":"yellow_card","number":0,"points":"0"},{"id":"red_card","type":"red_card","number":0,"points":"1"},{"id":"yellow_red_card","type":"yellow_red_card","number":0,"points":"0"},{"id":"total","type":"total","number":0,"points":"1"},{"id":"period_1st_half","type":"period_1st_half","number":0,"points":"1"}],"competitor_id":"betting:19:betting:1:sr:competitor:166150","side":"home"},{"scores":[{"id":"total","type":"total","number":0,"points":"2"},{"id":"period_1st_half","type":"period_1st_half","number":0,"points":"2"},{"id":"yellow_card","type":"yellow_card","number":0,"points":"0"},{"id":"red_card","type":"red_card","number":0,"points":"3"},{"id":"yellow_red_card","type":"yellow_red_card","number":0,"points":"0"}],"competitor_id":"betting:17:gin:361ba1ca-7c76-4fef-a703-2c7f8c2d9cdb","side":"away"}]} ... 7434 {"sport_event_id":"e5412aaa-bba5-4251-b027-00b61152486d","sport_id": "football","version":"22hAUGMBUcD000007gfQzu","timestamp_ns":1715096715000000000,"event_type":"markets_updated","payload":[{"id":"240h1_5","odds":[{"id":"1","value":"2.27","status":0,"is_active":true},{"id":"2","value":"1.62","status":0,"is_active":true}],"status":0,"type_id":240,"specifiers":"hcp=1.5"}]}
Most common issues:
- received 400 HTTP code: requested version is not specified in
Last-Version
header - received 409 HTTP code: requested version has already expired, you must to resync all sport events (go to step 1)
- received 400 HTTP code: requested version is not specified in
-
Every log contains the
version
, after applying changes from the log, theversion
should be saved ( similar to step 2) in order to be used for re-subscription (if the client's server restarts, the client has to start from step 3)
Usage of RabbitMQ API (deprecated)
Deprecated
We are aiming to provide feed with the lowest latency possible. So, as the RabbitMQ creates a big delay on routing data we don't support it anymore.
Reference
RabbitMQ queue and message
The name of a queue and credentials to connect to RabbitMQ server is provided by the DATA.BET integration team. The queue set up with length limit 10 000 messages. If the consumer does not consume messages (or a consuming rate much lower than a publishing rate), the publisher stops sending messages until the consumer resumes its work. If the publisher registers the recovery of the consumer (the queue size is less than 10 000 messages), the publisher will continue to publish messages.
Every RabbitMQ message body contains a single log. Every RabbitMQ message contains next properties:
- Content type - it's always
application/json
- Message ID - it's a version of a log and could be used as idempotence key
- Timestamp - time when message is sent
- Type - represents
event_type
of LogEntry, it could be used on client side to select JSON deserializer/decoder for receivedpayload
(everyevent_type
has ownpayload
) - Headers - contains metadata (some fields duplicate the properties described above)
Headers contains next fields:
- Sport-Event-ID
- ID of sport event
- Sport-ID
- ID of sport
- Last-Version
- a version of a log
- Event-Type
- an event type of log
The correct way to use the API
- Initialize sending messages to rabbitmq queue via
POST /subscribe
. If this is not the first interaction client must specify the last savedversion
(from step 2). If this is the first interaction, there is no need to specifyversion
. Every call of this method will purge the queue.- If the specified
version
is found and the difference between the specifiedversion
and the lastversion
on the server is less than 1 hour, new logs (logs newer than the specified version) will be sent.Resubscribe with specified version
client.crt
andclient.key
will be provided by the DATA.BET integration team.The response:1 2 3 4 5 6
stdbuf -oL curl --request POST \ --url https://feed.int.databet.cloud/subscribe \ --cert client.crt \ --key client.key \ --header 'Last-Version: 22hAUGMBUcD000004gfQzu' \ --verbose \
Response returns1 2 3 4 5
< Vary: Accept-Encoding < X-Api-Version: 2 < Date: Tue, 07 May 2024 20:00:42 GMT < {"version_is_found": true}
{"version_is_found": true}
and only new logs (updates that have happened since the update of the specifiedversion
in request took place) will be sent. - If the specified
version
is found and the difference between the specifiedversion
and the lastversion
on the server is more than 1 hour the optimization will be applied in order to reduce synchronization time: the server will first send snapshots of all sports events (eventsport_event_snapshot
) that have been updated since the update of the givenversion
took place and after that new logs will be sent (logs newer than the last sentsport_event_snapshot
). - If
version
is not specified (the first interaction) or is not found (the log is not available, retention period is 3 days) the server will first send snapshots for all available sports events (sport_event_snapshot
event) and after that new logs (logs newer than the last sentsport_event_snapshot
).Initialize sending messages to rabbitmq queue via curl
client.crt
andclient.key
will be provided by the DATA.BET integration team.The response:1 2 3 4 5
stdbuf -oL curl --request POST \ --url https://feed.int.databet.cloud/subscribe \ --cert client.crt \ --key client.key \ --verbose \
Response returns1 2 3 4 5 6
... < Vary: Accept-Encoding < X-Api-Version: 2 < Date: Tue, 07 May 2024 20:00:42 GMT < {"version_is_found": false}
{"version_is_found": false}
which is expected for initial request (becauseversion
was not specified).
- If the specified
- Subscribe to RabbitMQ queue (will be provided by the DATA.BET integration team). Every RabbitMQ message body contains a single log. Every log contains the
version
, after applying changes from the log, theversion
should be saved in order to be used for re-subscription. - If a client restarts it should start from step 1 with specifying last
version
from step 2.
Important notes:
- step 1 MUST be done before step 2 (the client must not execute two steps at the same time).
Refetch the snapshot for a specific sport event
The client can refetch a snapshot for a specific sport event (due to the logs of the sports being lost or incorrectly applied) by sending the request POST /refetch/sport-event/{sportEventId}
, A sport_event_added
log entry will be added to the log with the latest version of sport event.
Betting and Display Conditions
The following sport event properties MUST be taken into account when accepting bets, processing cashouts, and displaying sport events in the line for all integrations. Our Managed trading services (MTS) provides an additional layer of protection by checking all these statuses on our side. For non-MTS integrations, these conditions are mandatory requirements that must be implemented:
- Risk management integrations: Must implement these checks in the UI (e.g., locking markets, hiding sport events)
- Advisory API integrations: Must verify every bet placement and cashout request against all these statuses
Fixture status
There are 9 fixture statuses:
0 - not started (prematch sport event)
1 - live (live sport event)
2 - suspended (sport event could return to Live
(1))
3 - ended (sport event is ended)
4 - closed (sport event will never become live/prematch)
5 - cancelled (deprecated) (sport event is cancelled, will never become live/prematch)
6 - abandoned (deprecated) (will never become live/prematch)
7 - delayed (sport event postponed to a different time, can become live/prematch)
8 - unknown (status applies when none of the other statuses would be correct, regardless of whether the event is new, can become live/prematch)
Placing bets and accepting cashouts must be allowed only in not started
(0) and live
(1) statuses.
Sport event must be visible for bettors in not started
(0) and live
(1) and suspended
(2) statuses.
Market status
There are 5 market statuses:
0 - active (bets are allowed)
1 - suspended (bets are currently not allowed but market could return to the active state)
2 - deactivated (market is not active, bets are not allowed)
3 - resulted (market has settled, bets are not allowed)
4 - cancelled (deprecated) (market is cancelled, bets are not allowed)
Placing bets and accepting cashouts must be allowed only in active
(0) status.
Suspended markets should be visible for bettor but their odds should be locked (bets are currently not allowed, but market could return to the active state)
Odd status and its active state
There are 7 odd statuses:
0 - not resulted (bets are allowed)
1 - win
2 - loss
3 - half win (asian handicaps)
4 - half loss (asian handicaps)
5 - refunded (all the bets MUST be refunded because market could not be settled, for example: market winner for the 5th round could not be resulted if a game ended in the 3rd round)
6 - cancelled (deprecated) (all the bets must be refunded because of the reason that doesn't match refunded
)
And Odd
has property is_active
- if it is false
- placing bets MUST be suspended. Therefore placing bets on Odd
MUST be allowed only if Odd
is active (is_active
is true
) AND odd status is not resulted
(0).
Bet stop
If a bet stop
flag is activated placing bets on this match must be suspended. Here is a description of the conditions when the flag is activated and deactivated, as well as the event that triggers this changes.
Connection monitoring and global bet stop
Connection monitoring includes:
-
Connection loss detection: If the connection to the feed is lost or you have not received any log or heartbeat for 2 specified heartbeat intervals, you MUST trigger a global bet stop on your side.
-
Message lag monitoring: It's essential to track the lag of each message by comparing the timestamp of
markets_updated
events with the current server time. If the lag exceeds 10 seconds, trigger global bet stop immediately.
When global bet stop is triggered, you must:
- Stop bet placement to all sport events immediately
- Hide all sport events from the betting line/UI
- Prevent any new bets or cashouts from being processed until connection is restored
This requirement applies to all integrations regardless of whether MTS risk management is applied. The global bet stop ensures data integrity and prevents placing bets on potentially outdated or incorrect information when the feed connection is compromised.
Implementation notes:
-
Monitor both log events and heartbeat messages to detect connection issues
-
Use the recommended 5-second heartbeat interval (2 intervals = 10 seconds timeout)
-
Track the lag of each message by comparing the timestamp of
markets_updated
events with the current server time. If the lag exceeds 10 seconds, trigger global bet stop immediately -
Implement immediate UI updates to hide all sport events when global bet stop is triggered
-
Resume normal operations only after connection is restored and fresh data is received
Summary
Placing bets must be allowed if only ALL conditions are met:
Fixture status is not started
(0) OR live
(1) AND
Market status is active
(0) AND
Odd status is not resulted
(0) and Odd is_active
AND
bet stop
flag is deactivated AND
Connection to the feed is healthy
An example of sport event
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 |
|
It's allowed to place bets on market.id
20 and its odds with id
2 and 3 because fixture
status is not started
( 0) AND market
status is active
AND odd status is not_resulted
(0) AND odd is active (is_active
=true
).
It's forbidden to place bets on market.id
20 and its odd with id
1 because odd is NOT active (is_active
=false
).
It's forbidden to place bets on any outcome of market.id
21 because market
status is suspended
(NOT active
).
Settlement & Resettlement
Settlement and resettlement are critical components of the betting lifecycle that ensure accurate bet outcomes and proper financial handling. This section covers the key principles and mechanisms for processing bet settlements.
Settlement Principles
For settlement processing, partners MUST rely primarily on odd statuses rather than market statuses. Market status should only be used to satisfy the Betting and Display conditions as outlined in the market status requirements.
Resettlement Requirements
Flexible Status Transitions
Partners MUST implement robust resettlement mechanisms that can handle any sequence of status transitions. There are no strict rules governing how odds move from status to status, as different models may employ various approaches for different sports.
Supported Transition Sequences
The system must support complex resettlement scenarios, including but not limited to:
not_resulted
→won
→lost
not_resulted
→lost
→not_resulted
→refunded
won
→not_resulted
→refunded
lost
→won
→lost
refunded
→not_resulted
→won
- Any other valid combination of status transitions
Implementation Requirements
- State Tracking: Maintain accurate bet state throughout all resettlement cycles
- Financial Reconciliation: Properly adjust player balances for each status change
Bets Rollback
Bets rollback is a specialized settlement mechanism that affects the settlement and resettlement process. For detailed information about the bets_rollback
event, including its parameters, reasons, and implementation requirements, refer to the bets_rollback section.
Settlement Impact
The bets_rollback
event directly impacts settlement and resettlement operations by:
- Cancelling Bets: All bets within the specified time range and markets are voided, regardless of their current settlement status
- Reversing Settlements: If bets have already been settled (won/lost), the rollback reverses these settlements and restores the original stake
- Financial Reconciliation: Player balances are adjusted to reflect the bet cancellation