The Google DAI API lets you implement Google DAI-enabled streams in environments where implementing the IMA SDK is not supported. We recommend that you still use IMA on platforms where the IMA SDK is supported. We recommend using the DAI API on the following platforms: - Samsung Smart TV (Tizen) - LG TV - HbbTV - Xbox (JavaScript apps) - KaiOS The API supports the basic capabilities provided by the IMA DAI SDK. For specific questions about compatibility or supported features, reach out to your Google account manager. ## Implement the DAI API for LIVE streams The DAI API supports linear (LIVE) streams using both HLS and DASH protocols. The steps described in this guide apply to both protocols. To integrate the API into your app for LIVE streams, complete the following steps: ### 1. Request a stream To request a livestream from the DAI API, make a POST call to the stream endpoint. The JSON response contains the stream manifest as well as associated DAI API endpoints and values. #### Example request body https://dai.google.com/linear/v1/dash/event/0ndl1dJcRmKDUPxTRjvdog/stream { "key1" : "value1", "stream_parameter1" : "value2" } > [!NOTE] > **Note:** `api_key` can be supplied using the `Authorization` HTTP header. #### Example response body { "stream_id":"c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS", "stream_manifest":"https://dai.google.com/linear/dash/pa/event/0ndl1dJcRmKDUPxTRjvdog/stream/c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS/manifest.mpd", "media_verification_url":"https://dai.google.com/view/p/service/linear/stream/c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS/loc/ATL/network/51636543/event/0ndl1dJcRmKDUPxTRjvdog/media/", "metadata_url":"https://dai.google.com/linear/v1/pa/event/0ndl1dJcRmKDUPxTRjvdog/stream/c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS/metadata", "session_update_url":"https://dai.google.com/linear/v1/pa/event/0ndl1dJcRmKDUPxTRjvdog/stream/c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS/session", "polling_frequency":10 } #### Error response In case of errors, standard HTTP error codes are returned with no JSON response body. Parse the JSON response and store the following values: stream_id : This value can be used to identify the returned stream. stream_manifest : This URL is passed to your media player for stream playback. media_verification_url : This URL is the base endpoint for tracking playback events. metadata_url : This URL is used to poll for periodic information about upcoming stream events. session_update_url : This URL is used to update stream request parameters sent during the initial stream request. Note that the parameters of this request replace all parameters set for the earlier stream. polling_frequency : The frequency, in seconds, when requesting updated AdBreak Metadata from the DAI API. ### 2. Poll for new AdBreak Metadata Set a timer to poll for new AdBreak Metadata at the polling frequency, using the metadata URL. If not specified in the stream response, the default recommended interval is 10 seconds. To optimize bandwidth, do the following: 1. Make an initial `GET` request to the `metadata_url` endpoint. - Omit the `delta_token` query parameter. This process lets the server return the full metadata for the stream's Digital Video Recorder (DVR) window. The DVR window contains the timeframe of the broadcast available for a viewer to rewind and play. The response includes a `next_delta_token` object field. 2. Store metadata on the client side. 3. Make subsequent calls using the `next_delta_token` value that the most recent response returns. Each response contains a `next_delta_token` value. Always send the latest value you receive. 4. Update the stored metadata to merge changes and remove obsolete ad breaks. Don't attempt to parse, construct, or modify the delta token. The token's format can change. Store the token as received, and pass the token back unchanged in the next request. #### Example initial request The initial request takes no query parameters and returns the full metadata: https://dai.google.com/linear/v1/pa/event/0ndl1dJcRmKDUPxTRjvdog/stream/c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS/metadata #### Example subsequent request Each subsequent request passes the `next_delta_token` value from the previous response as the `delta_token` parameter. The response contains the following: - Ads - Ad breaks - Tags that the server added or updated since the server issued the token. - An `obsolete_ad_break_ids` list of ad breaks to remove from your stored metadata The server omits ad breaks that haven't changed. The following example shows a subsequent poll using the delta token to fetch only these recent changes: https://dai.google.com/linear/v1/pa/event/0ndl1dJcRmKDUPxTRjvdog/stream/c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS/metadata?delta_token=eyJyYW5nZXMiOlt7InMiOjEsImUiOjJ9XX0 If successful, you see an output similar to the following: { "next_delta_token": "eyJyYW5nZXMiOlt7InMiOjEsImUiOjN9XX0", "obsolete_ad_break_ids": ["0003069407"], "tags":{ "google_1022389921":{ "ad":"0003069408_ad1", "ad_break_id":"0003069408", "type":"start" }, ... }, "ads":{ "0003069408_ad1":{ "ad_break_id":"0003069408", "position":1, "duration":10.01, "title":"External - Pod Midroll 1", ... } }, "ad_breaks":{ "0003069408":{ "type":"mid", "duration":30, "expected_duration":30, "ads":3 } } } ### 3. Listen to ID3 events and track playback events To verify that specific events have occurred in a video stream, follow these steps to handle ID3 events: 1. Store the media events in a queue, saving each media ID along with its timestamp (if surfaced by the player). 2. On each time update from the player, or at a set frequency (recommended 500 ms), check the media events queue for recently played events by comparing the event timestamps to the playhead. 3. For media events that you confirm have played, check the type by looking up the media ID in the stored ad break tags. Keep in mind that the stored tags only contain a prefix of the media ID so an exact match isn't possible. 4. Because your video player app polls the metadata URL periodically, a delay might occur between when your video player encounters an ID3 tag in the stream and when the associated metadata is available. If an ID3 tag isn't found in the stored tags, keep the tag in a queue and re-process the tag after the next metadata poll. Keep the event in the queue until processing finishes. 5. After you find the tag in the metadata, check the tag's `type` field against the ad event types listed in the following section. To keep track of whether the video player is playing an ad break, use events with the value `progress` from the `type` field. Don't send these events to the media verification endpoint. For all other event types, append the media ID to the media verification endpoint and make a `GET` request to track playback. 6. Remove the media event from the queue. #### Ad event types Each tag in the metadata `tags` object has one of the following event types: | Event type | Description | |---|---| | `start` | Runs at the beginning of the ad. | | `firstquartile` | Runs at the end of the first quartile of the ad. | | `midpoint` | Runs at the midpoint of the ad. | | `thirdquartile` | Runs at the end of the third quartile of the ad. | | `complete` | Runs at the end of the ad. | | `progress` | Runs periodically during an ad break, to signal that an ad break is playing. Don't send these events to the media verification endpoint. | #### Example request https://dai.google.com/view/p/service/linear/stream/c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS/loc/ATL/network/51636543/event/0ndl1dJcRmKDUPxTRjvdog/media/google_1022389921 #### Example responses Accepted for asynchronous verification - HTTP/1.1 202 Accepted Successful empty response - HTTP/1.1 204 No Content Media verification not found - HTTP/1.1 404 Not Found Media verification sent by someone else - HTTP/1.1 409 Conflict You can verify tracking events in [Stream Activity Monitor](https://support.google.com/admanager/answer/7009058). ### 4. Update livestream session parameters You might want to adjust your session parameters after a stream has been created. To do so, make a request to the session update URL. > [!WARNING] > **Warning:** This call overwrites all the existing stream parameters, so your request body must contain all relevant key-value pairs, not just those which have changed. #### Example request body https://dai.google.com/linear/v1/pa/event/0ndl1dJcRmKDUPxTRjvdog/stream/c4a5dad5-aaa8-4550-8acb-7cda3cdb21bb:DLS/session { key1 : "value1", stream_parameter1 : "value2" } #### Example response body Successful response would be to look for - HTTP/1.1 200 ## Limitations If using the API within webviews, the following limitations apply with respect to targeting: - UserAgent: The user agent parameter is passed as browser specific value instead of the underlying platform. - [`rdid`](https://support.google.com/admanager/answer/7320899), [`idtype`](https://support.google.com/admanager/answer/7320899), [`is_lat`](https://support.google.com/admanager/answer/7320899): The device ID is not properly passed, which limits the capabilities of the following features: - Frequency capping - Sequential ad rotation - Audience segmentation and targeting ## Best practices Keep in mind that the metadata endpoint for livestream indexes is based on the prefix of the corresponding ID3 tag. This is by design to prevent the use of the metadata endpoint for immediately pinging all of the verification nodes. ## Additional resources - [API reference documentation](https://developers.google.com/ad-manager/dynamic-ad-insertion/api/full-service/reference/live) - [Simple sample](https://github.com/googleads/googleads-dynamic-ad-insertion/tree/master/simple/Live) - [IMA SDK documentation](https://developers.google.com/interactive-media-ads) - [DAI layer implementation types comparison](https://support.google.com/admanager/answer/9840889)