# Events

*"An event in a match is something that happens that affects the state of the match. Something of interest, or something that affects the state of the match from a betting perspective"*

As briefly discussed in the match information section, both the the full feed and the delta feed will usually contain one or more events. In this chapter we will show an XML example of what an event-element looks like, and what attributes are possible to be added for all sports.

**XML example**

```xml
<match matchid="1271072" ... >
<events>
<event id="201108605" info="Betstop - Possible goal [T2]" mtime="00:13" side="none" stime="1395846231756" type="1011"/>
</events>
</match>
```

***XML attributes definition***

<table><thead><tr><th width="121.0711669921875">Element</th><th width="121.815185546875">Attributes</th><th>Description</th><th>Possible values</th></tr></thead><tbody><tr><td>event</td><td>id</td><td>The unique identifier for this specific occurrence of this event. No other event (also not of the same type) will have the same id. </td><td><p></p><pre><code>(Deprecated)
</code></pre></td></tr><tr><td></td><td><em>uuid</em></td><td>The unique identifier for this specific occurrence of this event. No other event (also not of the same type) will have the same uuid.</td><td>UUID string</td></tr><tr><td></td><td><em>info</em></td><td>A description of the event.</td><td>String</td></tr><tr><td></td><td><em>mtime</em></td><td>The matchtime when the event<br>happened.</td><td>String. Format:<br>MM:SS</td></tr><tr><td></td><td><em>side</em></td><td>What team the event happened for.</td><td>String. Possible values:<br>none<br>home<br>away</td></tr><tr><td></td><td><em>stime</em></td><td><p>When the event was entered by Scout.</p><p>This attribute conveys the time whereat the event was entered. Thus if a scout loses connection and enters events whilst offline, upon reconnecting you will receive events where the <em>stime</em> attribute is different from the current time.</p></td><td>Timestamp</td></tr><tr><td></td><td><em>type</em></td><td>Event type id.</td><td>Integer</td></tr></tbody></table>

{% hint style="info" %}
**Note**\
The overview above only describes attributes which are present for all sports. In addition to this each sport has their own specific attributes for events. For a full overview of what attributes are present for each sport, see the individual sport specific sections.
{% endhint %}

<br>

### FAQ <a href="#ldevents-faq" id="ldevents-faq"></a>

#### &#x20;What is Betstop with ID 1073741822? <a href="#ldevents-whatisbetstopwithid1073741822" id="ldevents-whatisbetstopwithid1073741822"></a>

Occasionally  you  might  receive  a  Betstop  event  with  ID:  107374182.  This  event  is  sent  to  customers whenever there is a potential issue within the delivery pipeline specific to your connection. This Betstop event is not related to the actual match itself. When the health check of the delivery pipeline is back to normal, you will receive a full feed update message without the Betstop.\
Several key behaviors of Betstop event with ID: 1073741822:

1. when this event is first sent, it will come via a full feed message. It will never be sent as a delta.
2. this event will always appear at the end of the fullfeed message.
3. this event may have lower stime than the other events
4. in all subsequent fullfeed messages this particular Betstop event will not appear

<br>

#### How do you suggest keeping track of the sequence of events? <a href="#ldevents-howdoyousuggestkeepingtrackofthesequenceofevents" id="ldevents-howdoyousuggestkeepingtrackofthesequenceofevents"></a>

<br>

* Each event is sent with ***stime*****&#x20;attribute** to show the initial time of creation
* The technical Receiving order of the delta events is the correct event sequence. \
  There are queueing mechanisms in place that ensure the right order **for two events with the same&#x20;*****stime.***\
  \
  Currently we recommend to process events in the receiving order on customer side when the stime is the same.\
  \ <br>
* Within the uninterrupted connection, the deprecated *id* attribute keeps incremental order and however is NOT recommended to use if an ordered event reference is necessary. \
  Customers use it at own risk because:\
  \- upon disconnection from the feed for any reason, the newly retrieved feed may contain different ID values for the same events. UUID values will remain the same,
* The real sequence of  sport events by stime attribute is not guaranteed at all times due to the nature of data acquisition on live events. Feed contains deletions and insertions - delta messages modify the feed. (see ***happenedat** attribute)*<br>


---

# 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/live-data/introduction/system-communication/xml-messages-sent-from-the-betradar-system/events.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.