# 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:

<figure><img src="/files/KPQsx07in71OjfuWyPM7" alt=""><figcaption></figcaption></figure>

*The above image illustrates the syntax and ordering of the message queue.*&#x20;

1. **Priority (hi/lo/-)**: Is this a timing sensitive message (bet\_settlement messages are considered not timing sensitive)?
2. **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*.
3. **Live interest (live/-)**: Is this message interesting for live odds only system?
4. **Message type(s)**: odds\_change, bet\_settlement, bet\_stop, cancelbet, rollback\_betsettlement, rollback\_cancelbet, fixture\_change, alive.
5. **Sport (Sport ID/-)**: 1 = *Soccer*, 2 = *Basketball*, 3 = *Baseball*, etc (<https://iodocs.betradar.com/unifiedfeed#Sport-event-information-GET-All-available-sports>).
6. **URN** **for sport-event id**: *sr:match*
7. **Sport-event id without URN**: *123456*
8. **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.-.-.-                |

{% hint style="success" %}
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.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sportradar.com/uof/data-and-features/messages/amqp-topic-filtering.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.