Introduction to the API structure and data model

We’ve created a simple guide to API concepts, data model and usage, to help you build your video workflows on MK.IO.

If you are an existing AMS users, this should help you on your transition journey to MK.IOand aligning with our implementation outlined in the migration guide.

Let’s explore the API

The API is conceptually broken into four parts: Inputs, Assets, Streaming Locators, and Streaming Endpoints.

4 building blocks of the API

4 building blocks of the API


Inputs are ways of getting content into the system.

  • Content comes in and is transformed into an Asset.
  • Static content is pitched to blob storage and transformed using a job.
  • Live content is ingested (Live Event) and a time-shift buffer is defined using live output.


Assets are where content is stored on Blob storage and are decoupled from inputs for use at a later date.

Content protection and rewrites

Streaming locators connect DRM and filters to the asset for a dynamic packager (JITP) to process. Streaming locators are for DRM and manifest rewrites; you can have several per asset.


Streaming Endpoints define a domain name for content and provide an option for configuring front door and CDN for the user: Streaming Endpoints are for scaling output and integrating with CDN.

Every locator is available at every endpoint.

Data Model

Everything within MK.IO revolves around an Asset -> Inputs, either file-based or live are treated as assets on the output side.

Data model

Data model

Assets then have policies attached to them via a Streaming Locator, which can then be bound to a Streaming Endpoint for delivery.

Let’s take a look at each of these in turn.