> 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/understand-connected-vast-openrtb-and-cats-demand.md).

# Understand connected VAST, OpenRTB, and CATS demand

Understand how certified VAST, OpenRTB, and CATS demand sources compete with Podigee campaigns.

Podigee Audio Video Ad Server can use a connected demand provider as one source of an ad decision. The provider does not replace your Campaigns, Creatives, Inventory, policies, or measurement rules. It supplies a possible ad when its connection is active, its response is eligible, and the demand order allows it to compete.

This article explains the operator view. It does not explain how to create credentials or certify a provider. Those procedures belong in the Integrations collection.

## What the three standards mean

The standard describes how Podigee exchanges a request and response with a provider. It does not decide which source wins. The active demand policy, the request context, and the provider result decide that.

| Standard | What it does                                                                   | Typical result                                                                 |
| -------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ |
| VAST     | Describes an ad response, media files, wrappers, and tracking events.          | A provider returns a playable audio or video ad and its tracking instructions. |
| OpenRTB  | Defines an auction request and response between a seller and a demand source.  | A provider returns a bid, a no-bid, or a response that cannot be used.         |
| CATS     | Defines a connected demand request and response contract supported by Podigee. | A provider returns a supported demand result or no-fill response.              |

Podigee stores the selected standard and provider operation on the Flight. This makes the demand source visible when an operator reviews eligibility, delivery, or revenue evidence.

## How connected demand enters a Flight

Open **Monetization > Campaigns**, open a Campaign, and choose **Add flight**. The form starts with Podigee delivery. This is the normal choice for a Campaign that uses a Podigee Creative.

![The One Podigee Add flight form shows the delivery destination and the choice between Podigee delivery and a connected demand provider.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-5fc4e4d261a5d8c83f52f4569ec7dfeb55c32a06%2Fdoc-monetization-034-add-flight.jpg?alt=media)

*Choose a connected provider only when its connection has passed the required checks.*

Choose **Connected demand provider** only when a certified provider is available. Podigee then shows the provider, protocol, and operation fields.

* **Demand provider** identifies the active connection.
* **Provider protocol** identifies VAST, OpenRTB, or CATS.
* **Provider operation** identifies the certified action for that provider and protocol.

The lists are not free text. They are built from the active provider authority and its certified capabilities. If a provider, protocol, or operation is missing, do not enter a value by hand. The connection is not ready for that use, or the current account does not have the required authority.

The Flight still needs its normal settings:

* delivery destination and media kind;
* Inventory package and measurement contract;
* delivery goal, price model, rate, and currency;
* schedule, markets, content categories, and frequency rules;
* pacing, priority, and the applicable review policy.

Adding a provider binding does not publish the Flight. The normal proposal, review, approval, and publication rules still apply.

## How competition works

At request time, Podigee evaluates the request against the active release and the exact Flight version. It checks the episode and break, media kind, destination, market, privacy mode, schedule, frequency rules, capacity, Creative rights, and demand authority.

The demand policy defines the order in which eligible sources compete. A direct-sold Campaign can win before an external provider. A provider can compete only when it passes the same request rules and its connection is active for the required period.

![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.*

The simplified decision path is:

1. Podigee removes sources that cannot serve the request.
2. Podigee applies the demand order and price rules.
3. An eligible external source receives the standard-specific request.
4. Podigee validates the response, media authority, tracking authority, and commercial rules.
5. Podigee selects the result, tries the next eligible source, or uses the configured no-fill outcome.

A provider timeout, invalid response, unsupported media, or failed tracking authority is not a successful fill. The request can continue to the next source or to the configured fallback. It must not create a paid result when the measurement contract did not qualify the delivery.

## Example: an RSS audio request

Assume a Campaign has a Flight for **Podcast apps and RSS**, an audio Inventory package, and a VAST connection. When a listener requests an eligible episode:

1. Podigee checks the episode, break, listener context, Flight, and demand policy.
2. If the VAST Flight is next and eligible, Podigee sends the certified provider request.
3. The provider returns a playable response, no-fill, timeout, or invalid response.
4. Podigee validates the result and either selects it, tries the next source, or uses fallback.
5. The decision and qualified measurement record the actual result. A provider request alone is not a delivery or a revenue record.

The listener receives the selected audio presentation through the normal Podigee RSS delivery path. The provider response does not change the RSS feed itself.

## Example: an HLS video request

Assume a Campaign has a video Flight for a Podigee HLS destination and an OpenRTB connection. When the player requests a presentation:

1. Podigee checks the video Inventory, break duration, player capability, and targeting rules.
2. Podigee sends an auction request when the external Flight is eligible and next in policy order.
3. Podigee validates the bid, price, media, and tracking data against the Flight contract.
4. The selected ad is placed in the HLS presentation, or the request uses the next source or safe fallback.
5. Delivery, audience, and qualified revenue evidence refer to the same presentation and decision.

The exact HLS behavior depends on the delivery destination and its measurement contract. A provider response is not proof that the player completed the ad.

## What an operator sees in evidence

Use **Monetization > Evidence & Money** to review the result. For an external demand attempt, the record should make the following clear:

* the Campaign and exact Flight version;
* the provider, protocol, and operation;
* the request time and delivery destination;
* the result, such as bid, no-bid, timeout, rejection, or selected;
* the reason when the response was not eligible;
* the selected Creative or fallback;
* the measurement state and qualified value, if any.

The provider result and the Podigee decision are related, but they are not the same record. A provider can report a bid while Podigee rejects it because of policy, price, media, rights, or measurement rules. Keep both records when you investigate a difference.

## When a provider does not appear

Check these items in order:

1. Open **Monetization > Integrations** and confirm that the connection is active.
2. Confirm that the provider has current certification evidence for the required use.
3. Confirm that the provider supports the selected media kind and delivery destination.
4. Confirm that the provider supports the required protocol and operation.
5. Check the provider's authority period and the Campaign's schedule.
6. Review **Monetization > Operations** for a blocked, expired, or suspended connection.

Do not copy a provider ID or operation from an older Flight. A new provider version or a changed certification result can make an older binding unavailable. Select a current provider from the form after the connection is repaired.

## Safe operating rules

* Keep Podigee delivery for direct-sold Campaigns unless an external provider is required.
* Treat VAST, OpenRTB, and CATS as separate certified capabilities.
* Do not call a provider bid a delivered ad until the Podigee decision and measurement agree.
* Keep no-fill behavior explicit. Use the next eligible source, a house Flight, or clean content according to the active policy.
* Use the provider and decision evidence together when you investigate a dispute.
* Keep platform-controlled destinations, such as Spotify, in their own integration boundary.

## Expected result

The operator can see which connected demand source may compete, which standard and operation it uses, and why it won or did not win. The listener receives only a response that passes Podigee's eligibility and delivery rules, and the resulting delivery and money records describe the same request.


---

# 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/understand-connected-vast-openrtb-and-cats-demand.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.