> For the complete documentation index, see [llms.txt](https://docs.sportradar.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sportradar.com/uof/data-and-features/messages/amqp-topic-filtering.md).
# 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.*
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 ().
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
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.sportradar.com/uof/data-and-features/messages/amqp-topic-filtering.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.