> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/concepts-and-reference/vast-openrtb-cats-and-hls-reference.md).

# VAST, OpenRTB, CATS, and HLS reference

Understand the supported VAST, OpenRTB, CATS, and HLS profiles, required fields, limits, privacy rules, errors, and evidence before you activate an integration.

Use this article to choose a standards profile and to understand what each profile proves. The exact machine-readable schemas and API contracts are maintained in API Reference. This article explains the operator meaning and the checks that appear in Monetization.

## Standard ownership

| Standard | Main purpose                                   | Who controls the response                            | Typical use                                           |
| -------- | ---------------------------------------------- | ---------------------------------------------------- | ----------------------------------------------------- |
| VAST     | Describe a playable ad and tracking events     | The demand provider supplies the response            | Audio or video demand with a media file and tracking. |
| OpenRTB  | Exchange an opportunity and a bid              | The demand provider returns a bid or no-bid          | Auction demand and price-based selection.             |
| CATS     | Carry an approved ad transport message         | The certified provider supplies the transport result | Non-auction or post-auction transport.                |
| HLS      | Deliver a presentation and interstitial assets | The host controls the playlist and asset decision    | Podigee HLS and Apple Podcasts video delivery.        |

A valid response is not automatically a qualified impression. The response must pass eligibility, media, privacy, integrity, tracking, playback, and evidence checks.

## VAST profile

### Required response shape

The active VAST profile must identify the version and provide one valid ad response. The response normally contains:

* `VAST` and `version`;
* `Ad` and a stable provider ad identifier;
* `InLine` or an allowed `Wrapper`;
* `AdSystem` and `AdTitle`;
* one or more `Impression` URLs;
* `Creatives` with the supported media type and duration;
* `MediaFile` or the approved media resource;
* `TrackingEvents` and an `Error` URL when the profile requires them;
* the advertiser, category, disclosure, and Universal Ad ID values when the contract requires them.

The validator rejects an invalid XML document, an unsafe redirect, a wrapper loop, an unsupported media file, a missing duration, or a response that contains a field outside the certified profile.

### VAST checks

1. Check the XML and declared VAST version.
2. Check the wrapper and redirect limits.
3. Check the media file, codec, duration, dimensions, and language.
4. Check impression, tracking, and error destinations.
5. Check advertiser, category, disclosure, and Universal Ad ID data.
6. Check the response against the selected media kind and delivery surface.
7. Record the provider result and the fallback when a check fails.

Do not treat a playable media URL as proof of delivery. Playback and qualified evidence still need the declared event path.

![Active demand routing rules show the source order, minimum CPM, response limit, and no-fill outcome.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-3300aa6f6beb817f111c20442043939d962b3178%2Fdoc-monetization-019-demand-rules-active.png?alt=media)

*Demand order is a policy decision. Connecting a provider does not silently change that order.*

## OpenRTB profile

### Request and response meaning

An OpenRTB request describes one opportunity. It can include:

* a request ID and opportunity time;
* the available audio or video placement;
* duration, position, and pod information;
* market, content, and privacy signals allowed by policy;
* currency, floor, timeout, and destination constraints;
* a provider capability and operation reference.

An OpenRTB response can contain a bid, a no-bid result, or an error. A bid normally includes:

* a bid ID and price;
* the bid currency;
* the creative or ad reference;
* the media resource and duration;
* impression, tracking, and error events;
* the declared advertiser, category, disclosure, and deal information.

The bid is eligible only when the price, currency, media, market, privacy, policy, and Flight rules match. A bid does not guarantee a fill or a qualified impression.

### OpenRTB checks

1. Check the request and response IDs.
2. Check the timeout and provider operation.
3. Check the bid price, currency, and floor.
4. Check the media kind, duration, and delivery surface.
5. Check the advertiser, category, and disclosure values.
6. Check privacy and consent fields against the active policy.
7. Check the tracking and error events.
8. Store the redacted provider result and the final decision reason.

Do not put raw identity, credentials, or unapproved personal data in a request. Do not use a bid price from one currency as if it were a price in another currency.

## CATS profile

The approved CATS profile is CATS 1.0. A provider extension needs its own certified profile. CATS transports a result. It does not replace demand order, eligibility, or fallback policy.

A valid CATS message must preserve the approved references for:

* workspace, opportunity, and exact Flight version;
* destination, media kind, break position, and available duration;
* market, content category, privacy, and consent state;
* price, currency, fee, and commercial result when included;
* provider message ID, operation, and capability;
* media resource, tracking, error, extension, and integrity data.

The message must pass schema, signature, digest, identifier, endpoint, credential, media, and timeout checks. A failed message continues to the next eligible source or the declared fallback.

## HLS profile

HLS is a delivery contract, not a demand auction. It can carry a complete audio or video presentation and a declared interstitial.

### Playlist requirements

* The multivariant playlist lists only prepared and compatible variants.
* Media playlists use valid segments, durations, sequence information, and MIME types.
* Audio and video renditions have the required codecs, sample rates, dimensions, and bandwidth.
* Captions and I-frame variants appear when the destination requires them.
* The presentation uses the approved interstitial form, such as `#EXT-X-DATERANGE` with `X-ASSET-URI` or the dynamic `X-ASSET-LIST` response.
* Asset and manifest URLs remain durable for the required playback and replay period.
* CORS, cache, and content headers match the selected surface.

### HLS checks

1. Validate the multivariant and media playlists.
2. Validate every referenced segment and interstitial asset.
3. Check audio, video, captions, I-frame, codec, and bandwidth requirements.
4. Check interstitial timing and duration.
5. Check the asset-list request, response, and cache behavior.
6. Check CORS, MIME, URL durability, and fallback behavior.
7. Replay the presentation after a new decision and after a clean fallback.
8. Record the manifest, decision, cache, analytics, and qualified money evidence.

An HLS playlist can be syntactically valid and still fail because the media is wrong, the interstitial is too long, the URL is not durable, or the event evidence does not match the presentation.

![The current One Podigee Recent ad decisions page shows selected ads for Video ad stitching, with the Campaign, Creative, podcast, episode, reason, and decision time.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-cea052c594c382ab94110b59563d6406d953fce0%2Fdoc-monetization-057-hls-decisions.png?alt=media)

*Use the HLS delivery method to separate video playback from RSS audio.*

## Privacy and data-use rules

All standards use the same data boundary:

* include only the market, content, media, consent, and provider signals allowed by policy;
* keep raw identity inside the trusted serving boundary;
* do not place identity, targeting, rates, budgets, or internal reasons in public URLs or cache keys;
* send only the minimum fields required by the certified provider contract;
* treat a missing consent or identity signal as unavailable;
* keep provider payloads redacted in operator evidence.

Changing a data-use purpose requires a new policy version and a new conformance result. A provider that accepts a field does not make the field lawful or permitted for the selected Campaign.

## Limits and timeout behavior

The active connector and policy show the values for:

* request timeout;
* wrapper or redirect depth;
* response size;
* media duration and file size;
* retry count and retry window;
* rate limit and concurrency;
* event retention and replay period;
* asset and manifest retention.

If a provider reaches a limit, the result is recorded as a specific failure. The request must use the next eligible source or the configured fallback within the source playback boundary.

## Stable error categories

| Error category          | Meaning                                                   | Operator action                                                      |
| ----------------------- | --------------------------------------------------------- | -------------------------------------------------------------------- |
| Schema or parse failure | The message does not match the certified profile          | Keep the response out of delivery and ask the provider to repair it. |
| Media failure           | The media is missing, unsupported, or incompatible        | Replace the rendition or provider response.                          |
| Privacy failure         | The payload uses a signal that policy does not permit     | Correct the mapping or use the no-consent path.                      |
| Integrity failure       | The signature, digest, or identifier is not valid         | Quarantine the result and inspect the connector version.             |
| Security failure        | The endpoint, redirect, credential, or URL is not allowed | Repair the secure configuration.                                     |
| Timeout or rate limit   | The provider did not respond within the boundary          | Follow the retry and fallback policy.                                |
| No-fill                 | The source returned no eligible ad                        | Continue with the next allowed source or fallback.                   |
| Provider rejection      | The external provider rejected the request                | Read the provider reason and escalate when needed.                   |
| Playback failure        | The player could not use the media or interstitial        | Keep the result non-billable and use the declared fallback.          |

Use the exact error and decision reason in Operations or Evidence & Money. Do not replace a reason with a generic no-fill label.

## Choose and test a profile

1. Open **Monetization > Integrations**.
2. Select the delivery surface, media kind, provider, and standard.
3. Confirm the exact contract version and capability state.
4. Review the privacy, timeout, media, fee, currency, and fallback rules.
5. Run the managed conformance checks with valid and invalid fixtures.
6. Inspect the redacted request, response, media, and event evidence.
7. Complete provider or platform certification when the destination owns that boundary.
8. Activate only the exact capability that passed the required checks.
9. Run one representative delivery and verify decision, cache, analytics, and money evidence.

The machine-readable schemas and exact API fields are in **API Reference**. Use this article for the operating meaning, and use the API contract for integration code.

## Expected result

The selected standard has a clear request, response, media, privacy, timeout, error, and evidence contract. Operators can tell whether a failure is a provider problem, a policy decision, a media problem, or a playback problem. Only a response and presentation that pass the complete contract can become qualified delivery or money evidence.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/concepts-and-reference/vast-openrtb-cats-and-hls-reference.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.