CMS and API integration
When building with Tuned Global APIs, it is helpful to think in terms of two layers.
The CMS layer
Where your content, editorial, or product team creates and manages objects such as pages, playlists, stations, carousels, tags, and promotional content.
The API layer
Where your application retrieves CMS-managed content, metadata, and structures, then displays them to users.
For example:
- A developer may retrieve a content page by its content key
- A product team may configure a homepage carousel in the CMS
- A curator may create a system playlist
- Tags may be assigned in the CMS, then used to return grouped content returned by the API
- A station or radio experience may be created editorially in the CMS and then exposed through the APIs.
Note: The CMS is not only used to create editorial objects such as pages, playlists, stations, and carousels. It is also used to search and manage the underlying catalogue. Content teams can find tracks, review metadata, apply tags, use chart data, and add catalogue items to playlists, stations, or other CMS-managed experiences that are later consumed through the APIs.
If you are a content manager or want to understand how these actions are performed in the CMS, see the Training videos section.
If you are implementing these experiences in an app, see the Developer quickstarts.
IDs, keys and values you will encounter
Not every CMS-driven reference is a numeric ID. In practice, API clients usually work with a mix of identifiers.
Content key | A unique page identifier used to retrieve a CMS-managed content page. This is especially important for content pages, homepages, and deep links. |
Playlist ID | The identifier of a CMS-managed system playlist. |
Station ID | The identifier of a CMS-managed station or radio experience. |
Tag value | A CMS-managed value used to group and retrieve content in discovery, shelf, search, and homepage experiences. |
Carousel destination | The object or destination linked from a carousel item, such as a playlist, station, album, artist, page, or external link. |
Catalogue item ID | The identifier of a catalogue item, such as a song, album, artist, or release, that may be searched, tagged, added to playlists or stations, and surfaced through the APIs. |
CMS object to API reference
CMS object | Main identifier or value | Typical technical use |
Content key | Retrieve a CMS-managed page, support routing, and support deep links. | |
Playlist ID | Retrieve or surface editorial playlist. | |
Station ID | Retrieve or surface editorial stations. | |
Tag value | Populate shelves, group content, and support discovery. | |
Destination object identifier | Link to a page, playlist, station, album, artist, or external destination. | |
Song, album, artist, or release ID | Search, retrieve, tag, organise, or add catalogue content to CMS-managed experiences such as playlists, stations, shelves, and pages. |
Why this matters for implementation teams
A common integration mistake is to treat content structure as something that must be handled entirely in the front end. This often creates unnecessary complexity.
In many cases, it is better to let the CMS handle:
- Page composition
- Promotional linking
- Playlist curation
- Station curation
- Carousel management
- Discovery and merchandising logic through tags
This allows your technical team to build against stable API contracts while giving your content team direct control over what appears in the experience.
For practical implementation examples, see the Developer quickstarts in this CMS section.
On this page
- CMS and API integration