Release notes
2024r9
POST call for sport event days in sport API
Previously, it was not possible to create values for the WOnSportEventDay drop-down list using the sport API. The values had to be created in Mediagenix Base platform first and then the values could be retrieved using the GET /eventDays drop-down call.
However, this meant a sports integration system could not create events for additional event days that were not in the system.
To avoid this extra step, the POST /eventDays call has been added to the sport API.
The request body consists of the following attributes:
-
id: the API reference of the value. -
name: the Description of the value.
An example of the body:
{
"id": "finale",
"name": "Finale"
}
When the request is sent, the value is created in the WOnSportEventDay drop-down list in Mediagenix Base platform and the value can be retrieved using the GET /eventDays call.
The YAML has been updated for these changes. The latest version can be retrieved by using the GET /api call.
API developers
The following was changed in the YAML:
At line 1162, the post call was added to the /eventDays path.
For easier viewing, the YAMLs can also be compared here: https://www.textcompare.org/yaml2024r2
League ID when updating seasons in sport API
Previously, when
a sport season was updated using the sport API, for example, by only changing the
titleattribute; andthe season already had a series linked,
the following error message would be returned, even though it was not the intention to move the sport season.
{
"statusCode": "422",
"message": "Operation cannot be completed due to violations",
"timestamp": "2024-03-01T12:09:39Z",
"concept": "Season",
"id": "9055969000",
"errors": [
{
"errorCode": "SPORT-00015",
"description": "$_A season which has content linked to it
cannot be moved to a different league.",
"data": []
}
]
}From this version, the behaviour of the POST and PUT /seasons call for updating a sport season has changed for the leagueId attribute. This used to be a mandatory attribute but this is no longer the case.
If the leagueId is
not part of the body of the call;
part of the body of the call and it is the same as the
leagueIdthat the season is already linked to,
the season is not moved and the other attributes are updated.
If the leagueId is different than the one the season is already linked to, and the season
does not have a series linked, the season is moved to the new league.
already has a series linked, the existing error is returned:
"errors": [
{
"errorCode": "SPORT-00015",
"description": "$_A season which has content linked to it
cannot be moved to a different league.",
"data": []A season always has to be created in a certain league. If the leagueId is not provided in the POST call to create a season, the default league defined in the site preferences is used (RN-2572). A note has been added in the YAML for the POST /season call.
The YAML has been updated for this change. It can be retrieved by using the GET /api call.
API developers
For API developers, the following parts of the YAML were updated. Parts in bold are new, while stricken parts are deleted.
Line 204
/seasons:
post:
summary: Create or update a season.
tags:
- Season
requestBody:
description: >
**Creating**: A season is always part of a sport league.
If attribute **leagueId** is not provided, WHATS'ON will use the default sport league
for season configured in the site preferences. If there is no default league configured,
the call will fail with an error.
required: true
content:
application/json:
schema:
required:
- leagueId
allOf:
- type: object
properties:
leagueId:
type: string
- $ref: "#/components/schemas/Season"For easier viewing, the YAMLs can also be compared here: https://www.textcompare.org/yaml
2023r10
Additional attributes in sports API
In a previous version, the following fields were added to the sport concepts: Sub type on sports league, season and event, and Group name and Event country on sport event (RN-5733).
From this version, they have been added to the appropriate calls in the sport API:
subTypein the body of
POST /leaguesPUT /leagues/{leagueId}POST /seasonsPUT /seasons/{seasontId}POST /eventsPUT /events/{eventId}
in the response of
GET /leagues/{leagueId}GET /leaguesGET /seasons/{seasontId}GET /seasonsGET /events/{eventId}GET /events
groupNameandcountryin the body of
POST /eventsPUT /events/{eventId}
in the response of
GET /events/{eventId}GET /events
For example GET /events/{eventtId}:
{
"sportEventId": "812818000",
"seasonId": "644363000",
"leagueId": "644362000",
"title": "Final",
"sportKind": "Soccer",
...
"subType": "Mens",
"country": "UK",
"groupName": "Final 2"
}
Since the country and subType attributes are drop-down lists, a GET /countries and /subTypes call have been added to retrieve the available values.
The YAML has been updated for these changes.
2022r7
Fix for POST /sportEvents call in sport API
Previously, when
creating a sport event for a season through the
POST /sportEventscall of the sport API,linking an episode to that event,
updating the event through the
POST /sportEventscall with the same body,
then the update would not be done even though nothing had changed, and the following error response was given:
{
"statusCode": "422",
"message": "Operation cannot be completed due to violations",
"timestamp": "2022-11-16T10:29:39Z",
"concept": "SportEvent",
"id": "10850401002",
"errors": [
{
"errorCode": "SPORT-00014",
"description": "$_A sport event which has content linked to it cannot be moved to a different season",
"data": []
}
]
}This issue has been fixed and the update is now done in this scenario.
2020r1.002
API version: v1.0.0
External reference cannot be cleared by BAPI
Within any POST and PUT call, if a an attribute is sent empty, WHATS'ON will clear that field. Previously, this was also possible with the external reference of a sport league, season, event, player or team.
Now, this is fixed. When no external reference is provided but the attribute is sent empty or Null, we will ignore that tag and proceed as if there was no ID field (external reference) provided. This means that it should remain as is in a PUT call or return a new one in a POST call.
2017r1.006
API version: v1.0.0
Addition of On-demand schedule API
From this version on, it is possible to manage on-demand transmissions using the On-demand schedule API.