Kaltura’s OTT Backend features hundreds of REST-based APIs that provide programmable access to every OTT service. With full access to the OTT Backend API, you can extend every feature and functionality of the Kaltura Platform integrate Kaltura’s solutions, services, and widgets seamlessly, creating a unified experience within your chosen environments. This site provides comprehensive documentation on Kaltura’s OTT Backend API, and is intended to developers who wish to use these APIs within their services. To gain a greater understanding of Kaltura’s OTT Video Platform, please review the introduction to Kaltura OTT TV article.
The Kaltura OTT Backend platform exposes its Server API to applications by implementing a standard HTTP POST/GET url-encoded requests structure. Kaltura’s OTT Backend APIs are designed to follow REST principles; the APIs consist of service actions for querying, setting, updating and listing entities as well as for activating processes within Kaltura’s OTT platform. Service actions are grouped according to the entity type they are applied to, and provide all actions relevant to the specific entity. This API documentation provides specific information on:
Note: A prerequisite for using Kaltura’s OTT Backend APIs is obtaining Kaltura account identifiers such as Account ID and User ID.
Before you begin using Kaltura’s OTT Backend APIs, here are a few terms you should familiarize yourself with:
Term | Description |
---|---|
OTT | Over The Top: Video transmitted via the Internet without an operator of multiple cable controlling or distributing the content. |
KS | Kaltura Session: A valid KS must be passed with each call to Kaltura’s API. The session context embedded into a KS identifies your application, content access permissions, and API access permissions (it also contains other internal session data). This information is securely encrypted and hashed, preventing unauthorized manipulation of the session context. |
EPG | Electronic Program Guide: An application used with digital set-top boxes and newer television sets to list current and scheduled programs that are or will be available on each channel and a short summary or commentary for each program. EPG is the electronic equivalent of a printed television program guide. |
VOD | Video On Demand: Allows end users to watch video content whenever the user chooses. |
Asset | This is any Kaltura EPG program or VOD content. |
Channel | A set of Kaltura assets, selected manually or dynamically, using predefined filters. |
EPG Channel | Equivalent to a TV channel, this represents a set of EPG programs related to the same playable source on a single timeline. |
Group | A Kaltura OTT account owned by an operator. |
Household | A users account, which must be associated with a group, and is owned by the operator’s customers. |
OTT User | A specific user account that must be associated with household account. |
The following are the general characteristics of any REST API:
Although both form data and a Kaltura proprietary requests are supported, JSON is the recommended request format, as per the example below: (see https://ott.developer.kaltura.com/api-docs/Services/asset/asset_get for details):
{% highlight c %} { "apiVersion": "3.6.1579.29065", "assetReferenceType": "media", "clientTag": "dotnet:16-12-20", "format": 1, "id": "566254", "kalsig": "ef6ddd187091e42003f2c59dbbcdaf4f", "ks": "KS_STRING_HERE" } {% endhighlight %}
To define the required request format, use the Accept HTTP header with application/json or text/xml. The REST APIs use the following response formats:
{% highlight c %} JSON (format = 1, Accept: application/json) { "executionTime": 0.900651, "result": { "objectType": "KalturaLoginSession", "ks": " KS_STRING_HERE" } } {% endhighlight %}
{% highlight c %}
XML (format = 2 , Accept: text/xml)
A service represents a resource in the data mode that groups all actions that relevant to a specific object. For example, OTT-User, Recording, Asset.
An action represents read and write operations (CRUD) that expects known arguments and returns known objects. For example: add, update, delete. get, list.
All objects extend from the KalturaObjectBase (note that the name may be different in different coding languages):
Multi-requests enable sending multiple applicative requests in a single HTTP request.
{% highlight c %} { "apiVersion": "3.6.1579.29065", "ks": "KS_STRING_HERE", "0": { "service": "asset", "action": "list" }, "1": { "service": "channel", "action": "get" } } {% endhighlight %}
This enables using responses from one applicative request in another applicative request in the same HTTP request.
{% highlight c %} { "apiVersion": "3.6.1579.29065", "ks": "KS_STRING_HERE", "0": { "service": "ottUser", "action": "anonymousLogin", "partnerId": 203345 }, "1": { "service": "asset", "action": "list", "ks": "{1:result:ks}" } } {% endhighlight %}
The Kaltura Ott Backend API utilizes the following global parameters:
All HTTP requests are expected to return HTTP 200, OK, even in case of an applicative error. Errors are returned in the serialized response (JSON or XML) and automatically interpreted by all client libraries. In case of a regular request (not multi-request) the client library will throw the exception and raise the error to the error handling callback (depending on the coding language); however, in case of errors inside a multi-request, the exception object will be returned in the results array and should be handled manually by the application.
XML:
{% highlight c %}
500016
JSON:
{% highlight c %} { "executionTime": 0.0007125, "result": { "error": { "objectType": "KalturaAPIException", "message": "KS expired", "code": "500016" } } } {% endhighlight %}
Multi-request:
{% highlight c %} { "executionTime": 3.40099, "result": [ { "objectType": "KalturaLoginSession", "refreshToken": "vsdvssdp046ab84d27b1abb6djowdsd34", "ks": "VALID_KS_STRING" }, { "error": { "objectType": "KalturaAPIException", "message": "Search failed", "code": "1" } } ] } {% endhighlight %}
TVP-API works with refresh-token, a long-lived token that is created upon login, and an access-token, a short-lived token that used in any request to authenticate the user, the access-token is retrieved from the server using the refresh-token. Requests to TVP-API should be accompanied with init-object that contains the access-token. Requests to the OTT API can be accompanied by a ks property; this property will usually contain a KS as returned from the OTT API login, but it may also contain an access-token instead. When the access-token is used instead of KS, no init-object is needed; for example https://ott.developer.kaltura.com/api-docs/Services/asset/asset_get:
{% highlight c %} { "apiVersion": "3.6.1579.29065", "assetReferenceType": "media", "clientTag": "dotnet:16-12-20", "format": 1, "id": "566254", "kalsig": "ef6ddd187091e42003f2c59dbbcdaf4f", "ks": "KS_STRING_HERE" } {% endhighlight %}