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

<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

Element	Attributes	Description	Possible values
event	id	The unique identifier for this specific occurrence of this event. No other event (also not of the same type) will have the same id.	(Deprecated)
	uuid	The unique identifier for this specific occurrence of this event. No other event (also not of the same type) will have the same uuid.	UUID string
	info	A description of the event.	String
	mtime	The matchtime when the event happened.	String. Format: MM:SS
	side	What team the event happened for.	String. Possible values: none home away
	stime	When the event was entered by Scout. 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 stime attribute is different from the current time.	Timestamp
	type	Event type id.	Integer

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.

FAQ

What is Betstop with ID 1073741822?

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

How do you suggest keeping track of the sequence of events?

• Each event is sent with stime 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 stime. Currently we recommend to process events in the receiving order on customer side when the stime is the same.

• 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)