Release notes

2025r11

Fix for linked segmentation profiles

Previously, when sending a POST /completeMediaAssets call to update a media asset with a segmentation profile that was linked to transmissions, but the segmentationProfile array was not included in the call, the service would generate crash reports. This was because it would try to delete the profile since it was not included, but it was still linked. This was introduced by a previous fix. However, usually, objects are not updated if they are not included in the call.

This issue has been fixed in this version. If the segmentationProfile array is not included in the call, the profile will be ignored.

2025r10

Point in time custom attributes in business API

Custom attributes are supported in the content, copyright, MAM, on-demand schedule, person and trailer API.

Previously, the following types were available:

  • Boolean

  • Date

  • Decimal number

  • Drop-down list

  • Drop-down list for multiselection

  • Duration

  • Integer

  • Reference

  • String

  • Text

  • Web

From this version, custom attributes of the type Point in time can also be used in these APIs.

In the GET calls, such as GET /program, the following suffixes can be added to the call to either get only specified attributes in the response or all custom attributes of the supported types:

  • ?customAttributes=attributeName,attributeName

  • ?customAttributes=allCustomAttributes

For each custom attribute, the attribute name, value, and type will be given. The new type will be included in the response as follows:

...
    "customAttributes": [
        {
            "attributeName": "embargoTimestamp",
            "value": "2025-12-14T20:00:00Z",
            "type": "Point in time field"
        }
    ]
...

The Point in time custom attribute will be considered as a local timestamp in the Mediagenix Base platform in the default timezone, which is Brussels. When a GET call is done, the timestamp of the custom attribute is converted to UTC time.

For example, the Embargo timestamp from the example is 14/12/25 21:00:00. This is considered in the default timezone, Belgium, which is currently on UTC+1. When doing the GET call, the timestamp is returned as 2025-12-14T20:00:00Z.

In POST or PUT calls, an array of custom attributes needs to be provided with their attribute name and value. The new type should be specified as follows:

    "customAttributes": {
        "embargoTimestamp": "2025-12-14T20:00:00Z"
    }

The timestamp is converted from UTC to the default time zone before being saved in Mediagenix Base platform. This custom attribute type should follow the ISO 8601 format, meaning YYYY-MM-DDTHH:MM:SSZ.

For example, if 2025-12-14T20:00:00Z is sent, this will be saved as 21:00:00.

If the correct format is not used, the following error message is returned:

{
    "statusCode": "422",
    "message": "Operation cannot be completed due to violations",
    "timestamp": "2025-12-02T09:23:41Z",
    "concept": "Program",
    "id": "9502146329",
    "errors": [
        {
            "errorCode": "CORE-00002",
            "description": "Parsing error. Use ISO 8601 format",
            "data": [
                null
            ]
        }
    ]
}

API developers

The YAMLs will be updated in an upcoming version. Until then, the changes above can already be entered manually.

2025r9

Fix for incorrect payload

Previously, sending a malformed REST API payload to the content or MAM API (e.g., with an object instead of an array for certain fields like contentWarnings) would cause the business API interface service to crash.

Now, if a REST call with a payload with incorrectly placed brackets is sent, the system will return a 400 Bad Request error instead.

2025r6

Media position status added in MAM API calls

In version 2025r3, media positions were added to the MAM API.

In this version, the position status has been added to media positions.

Since an external partner might be responsible for each file, the status should be editable for external systems. Therefore, it has been added to the MAM API as well.

The status attribute has been added to the following calls:

  • POST /mediaPositions

  • PUT /mediaPositions/{mediaPositionId}

  • GET /mediaPositions

  • GET /mediaPositions/{mediaPositionId}

An example of the body of the POST /mediaPositions call:

{
    "mediaId": "229151000",
    "type": "OneDrive",
    "mediaPositionId": "9502009960",
    "subType": null,
    "position": "/movies",
    "url": null,
    "status": "Requested"
}

The attribute uses the API reference of the value in the MM2MediaPositionStatus drop-down list. Therefore, the GET /mediaPositionStatuses call has been added to retrieve all the active values and their references.

An example of the response:

[
    {
        "id": "Requested",
        "name": "Requested"
    },
    {
        "id": "Verification in progress",
        "name": "Verification in progress"
    },
    {
        "id": "Ready",
        "name": "Ready"
    }
]

API developers

The YAML has been updated for these changes. The latest version can be retrieved by using the GET /api call.

However, the YAML does not contain the correct path for the drop-down call. It should be /mediaPositionStatuses instead of /mediaPositionStatus.

At line 2404, the /mediaPositionStatus path was added.
At line 3449, the status property was added to the MediaPosition schema.

You can find more information about the body structure and fields in the provided Swagger file.

2025r3

Media positions on media in MAM API

The current positions on media describe the positions of managed media, such as server, file share... Additional fields were added to the concept in this version.

Previously, the positions could not be managed using the MAM API.

From this version, several calls for the current media positions have been added:

  • POST /mediaPositions:
    Create or update a media position for a specific media. The mediaId attribute is mandatory, while the type is only mandatory during creation.

  • PUT /mediaPositions/{mediaPositionId}:
    Update a media position on a media.

  • GET /mediaPositions/{mediaPositionId}:
    Retrieve the details of a specific media position.

  • DELETE /mediaPositions/{mediaPositionId}:
    Delete a media position.

  • GET /mediaPositions:
    Search for media positions using the type, subType or mediaId as filter parameters. For example: GET /mediaPositions?filter=eq(mediaId,169161)

An example of the response body of the GET /mediaPositions/{mediaPositionId} call:

{
    "mediaPositionId": "9501808044",
    "type": "FTP",
    "subType": "Videos",
    "mediaId": "1111456000",
    "position": "Files",
    "url": "file://FTP/videofolder"
}

The following drop-down calls were added to retrieve the values of the type and subtype attributes:

  • GET /mediaPositionTypes:
    Retrieves the values of the MM2ManagedMediaPositionType drop-down list.

  • GET /mediaPositionSubtypes:
    Retrieves the values of the MM2ManagedMediaPositionSubType drop-down list.

Additionally, the mediaPositions array was added to the existing GET /media/{mediaId} call. It returns the IDs of the positions on a media, so the mediaPosition calls can be used.

An example of the response:

{
    "label": "0000000041",
    "status": "available",
    "library": "The fiery library",
    "type": "MAM File",
    "networkPath": "/main",
    "TCIN": "00:00:00.00",
    "TCOUT": "01:30:00.00",
    "remarks": null,
    "MAMMediaId": "YEUZYEZ76765",
    "checksum": "67236IKJDKZ8USD",
    "filesize": 350,
    ...
    "linkedMediaAssets": [],
    "mediaPositions": [
        "9501807846",
        "9501808044"
    ]
}

API developers

The YAML has been updated for these changes. The latest version can be retrieved by using the GET /api call.

Quite a number of changes were done to YAML, so for easier viewing, the YAMLs can be compared here: TextCompare