API Changes
States and Types
We introduced states and types to ensure data quality and consistency for specific fields.
States
Types
Something has a type, when there are multiple variants of a certain variant.
For example, types for referees. Referees can be the head referee, the assistant referee or the fourth official. Due to types we qualify which variant of the belonging entity the specific referee is.
This was introduced to ensure all sports will follow the exact same structure in API 3.0.
New types: Position ID and detailed position ID are new types. Also, periods, sidelined, referees, events, standings, metadata, formations, colors, injuries, suspensions, predictions, and stats contain fields that belong to a type.
Strict typing
Strictly typed languages enforce typing on all data being interacted with. All data types strictly conform to standard JSON notations. In addition to data types being stricter, we also added types to various entities to ensure higher data consistency.
Scores
In API 2.0 the scores of a fixture are in the default API response. In API 3.0 this is not the case. For API 3 we've introduced the scores
include. This has been added to retrieve a score for fixtures more conveniently. The include returns the scores per period and the current score for the regarding fixture.
Participants vs localTeam & visitorTeam include
This might be one of the most important model changes in API 3.0. Previously, localTeam
and visitorTeam
were the includes to use to get all team data. The previous includes are replaced by our new include: participants.
From now on, this is the way to get information about the teams participating in a match.
Both teams that play in the fixture are present in the participants array and their location is located in the meta section of a team. Below is an example of how a fixture with this new include can look.
Rate limit per entity
Pagination
A new pagination system has been implemented. In API 3.0, we will no longer provide a count
and total_pages
property in the meta of the response. Instead, you can paginate using the has_more
parameter to determine if you can still propagate through results. This change decreases the load on our databases and massively increases API response speed and reliability.
In addition to that it is now possible to add the filters=populate to your query parameter. This parameter allows for a higher pagination limit (max 1000), so you can populate your database more conveniently instead of using the default pagination limit of 50. To prevent our services from overloading, using includes is disabled when this filter is added to the request.
Livescores endpoints
For API 2.0, we only had two live score endpoints. The “GET All Livescores” and “GET All In play Livescores”. The GET All Livescores endpoint gave all matches that would take place on that specific day, while the GET All In play Livescores endpoint would return all fixtures 15 minutes before they started. It will also disappear 15 minutes after the game is finished.
For API 3.0, there are three live score endpoints available. The “GET Inplay Livescores”, “GET All Livescores”, and the “GET Latest Updated Livescores”.
The GET Inplay Livescores: GET All Inplay Livescores: returns all the inplay fixtures.
GET All Livescores: Returns the fixtures 15 minutes before the game starts. It will also disappear 15 minutes after the game is finished.
GET Latest Updated Livescores: Returns all livescores that have received updates within 10 seconds.
When you need the fixtures that will take place on a specific date, you can use the “GET Fixtures by Date” endpoint. This returns the fixtures from your requested date.
Core and odds
Last updated