# Fixture Changes
### What is a Fixture?
A sports event that has been arranged to take place on a particular date and at a particular place. Fixture can be used as a synonym for match or competition, e.g. "Real Madrid vs FC Barcelona" would be an example of a fixture. The fixture endpoint on the API side provides all necessary Sportradar information to clients regarding such a sports event/match/competition before the match.
### Fixture Changes
A fixture\_change message is sent when a Betradar system has made a fixture change it deems as important. These are typical changes that affect events in the near term (e.g. a match was added that starts in the next few minutes, a match was delayed and starts in a couple of minutes, etc.).
The message is short and includes a bare minimum of relevant details about the addition/change. The recommended practice is to always do a follow-up API call to look up the updated fixture information.
The *fixture\_change* element in the message is made up of three attributes which are shown in the table below.
| **Name** | **Description** |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| event\_id | The match/race/tournament this fixture change is for |
| change\_type | (Optional) If specified, declares what type of change it is (new, start time, coverage).
The details are in the message for a start time change or coverage change. Otherwise, the new fixture has to be requested from the API.
1=NEW, 2=DATETIME, 3=CANCELLED, 4=FORMAT, 5=COVERAGE, 6=PITCHER
|
| product | The producer that generated this message.
1=LiveOdds, 2=MTS, 3=BetradarCtrl, 4=BetPal, 5=Premium Cricket etc
|
### Fixture Change Messages
```xml
```
#### change\_type Attribute
The *change\_type* attribute (if present), describes what type of change that caused the message to be sent. In general, best practices are to always re-fetch the updated fixture from the API and not solely rely on the change\_type and the message content. This is because multiple different changes could have been made.
The list of all the change types which trigger a *fixture\_change* message are listed in table below
| **Change** | **Id (Enum)** | **Description** |
| ---------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| NEW | 1 | This is a new match/event that has just been added |
| DATE\_TIME | 2 | Start-time update |
| CANCELLED | 3 | This sport-event will not take place. It has been cancelled |
| FORMAT | 4 | The format of the sport-event has been updated (e.g. the number of sets to play has been updated, or the length of the match, etc.) |
| COVERAGE | 5 | Coverage update. Sent for example when LiveOdds coverage for some reason cannot be offered for a match |
| PITCHER | 6 | Change of pitcher. Sent when the starting pitcher is changed before the match starts |
Though fixture changes for a particular event are provided in the XML feed, still, it is possible to request a list of all the fixture changes happened during the last 24 hours by means of the[ *fixture\_change API end point*](https://iodocs.betradar.com/#/Static%20sport%20event%20information/fixtureChanges) or by using the [SDK](https://docs.sportradar.com/uof/sdk).
The *event\_id* is provided and the time of the change as well. Once you get such info, you can use the fixture end point in order to retrieve more detailed info related to the change.
An example follows of the response of the fixture\_change API end point call.
XML example
```xml
```