AMQP Topic Filtering
Messages are sent on various topics that are intended to provide easy and flexible routing/filtering. The topic key is divided into 8 sections:

The above image illustrates the syntax and ordering of the message queue.
Priority (hi/lo/-): Is this a timing sensitive message (bet_settlement messages are considered not timing sensitive)?
Pre-match interest (pre/virt/-): Is this message interesting for a pre-match only system? For real sport-events prematch odds are sent with “pre” as the keyword. If this word is “virt”, it means this is prematch odds for one of Betradar’s virtual sports.
Live interest (live/-): Is this message interesting for live odds only system?
Message type(s): odds_change, bet_settlement, bet_stop, cancelbet, rollback_betsettlement, rollback_cancelbet, fixture_change, alive.
Sport (Sport ID/-): 1 = Soccer, 2 = Basketball, 3 = Baseball, etc (https://iodocs.betradar.com/unifiedfeed#Sport-event-information-GET-All-available-sports).
URN for sport-event id: sr:match
Sport-event id without URN: 123456
Node_id can be used for recovery to ensure that a session is not receiving recovery messages for another session for the same customer
Common topic key examples:
A pre-match odds update:
hi.pre.-.odds_change.1.sr:match.1234.-
A live odds update:
hi.-.live.odds_change.1.sr:match.1234.-
A Fixture change
hi.pre.live.fixture_change.1.sr:match.1234.-
A live bet-_settlement:
lo.-.live.bet_settlement.1.sr:match.1234.-
Post-match bet-settlement
lo.pre.-.bet_settlement.1.sr:match.1234.-
A virtual sport odds update
hi.virt.-.odds_change.1.vs:match.1234.-
An alive message
-.-.-.alive.-.-.-.-
A snapshot complete message
-.-.-.snapshot_complete.-.-.-
Unless you are binding to all messages (“#”), you will typically bind to at least two routing key patterns (e.g. “*.*.live.#” and “-.-.-.#”) because you are typically always interested in receiving the system messages that will come with a routing key starting with -.-.-
Betradar strongly recommends to have all binding patterns always end with .# to ensure backward compatibility if additions are made to the routing key.
Last updated
Was this helpful?