Indee Watch API

The Watch API allows enterprises to build their own applications to stream the media they have uploaded to Indee.

Pre-requisites

The Watch API is used by watch applications and will not be available for admin functionalities.
Support is available for all the different Indee products. An enterprise can choose one or more out of them.

Only one product of each kind will be supported at the moment. For example, an enterprise can have one FYC product and one Publicity product, but not two separate FYC products.

Each product will require you to issue and use a different API key.

Endpoint Classification

All the Watch API endpoints can be divided into 4 broad categories as shown below:

Auth

The auth endpoints can be used for various user-centered functionalities like signup, session management, password management, etc.

Content

The content endpoints can be used to get various details about the published content for an authenticated user.

Stream

The stream endpoints provide all the data needed to set up and run a media streaming session.

Mandatory Headers

ClientID

Every request made to the Watch API will require a client identifier to be passed in the headers. This lets Indee capture some details about the device being used by the end consumer and make some important decisions in terms of functionality accordingly.

Example: Video playback for streams in certain output formats is typically not supported on older models of various devices. With the help of this header, if we detect that the device falls in such a known category (criteria will be based on a corpus of historical data we have available), the playback endpoint can possibly return an appropriate response indicating a disparity upfront instead of the player running into unusual error states.

It's a good practice to enforce this from a security point of view as well.

The name of this header is ClientID. The value should be a string with 4 components separated by hyphens. The detailed spec is as below

For web clients

The format is as follows: web-{browser_name}-{browser_version}-{os_name}{os_version}

Example: web-safari-16.4-macos10.15.7

Implementation Recommendation: The first component (web) should be hardcoded. The other parts can be extracted from the user agent string with the help of packages like UAParser.

For native clients

The format is as follows: {device}-{model}-{app_version}-{os_name}{os_version}

Example: ipad-ipad4mini-6.0.3-ipados12.5.7

Implementation Recommendation: The first component ({device}) should be hardcoded. The other components can be extracted by using native functions specific to the client.

Client Identifier and implications

The client Identifier is used to provide specific customizations for some of the nuances of handling native client applications. Further this information is also used capture playback analytics by device. The device/version combination is used to determine if a particular client is outdated and accordingly provide upgrade messaging.

device	Usage
iPad	None
AppleTV	None
Roku	Reorder the sequence of audio tracks support studio specified ordering of audio tracks
Firestick	Checks for CMAF support and rendering CMAF content only for supported devices