> 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/connect-an-openrtb-demand-source.md).

# Connect an OpenRTB demand source

Configure and certify an OpenRTB demand source, then activate it only when auction and notice checks are complete.

Podigee Audio Video Ad Server can exchange a controlled auction request with an approved Open Real- Time Bidding (OpenRTB) demand source. After the first mention, this article uses Podigee Ad Server for the product name. OpenRTB lets a bidder return a bid or no-bid result for an eligible audio or video opportunity.

An OpenRTB connector is not a live auction by itself. Podigee must verify the provider contract, the request mapping, the seller identity, the supply-chain identity, the notice lifecycle, and the delivery and measurement rules before the source can compete.

## Before you start

* You have permission to configure and activate external demand integrations in the workspace.
* You have the bidder endpoint and current OpenRTB contract.
* You have an approved credential reference. Do not paste a secret into a form.
* You have a verified seller, seat, and supply-chain identity for the connection.
* You know the allowed markets, media types, request volume, timeout, currency, and fee rules.
* You have an owner for consent, privacy, billing, notice, and fallback decisions.

The current profile is OpenRTB 2.6, checked against the May 2025 release, with the required AdCOM objects pinned by the provider adapter. A provider can support a different version, but Podigee must certify that version separately.

## Open the connector form

1. Open **Monetization > Integrations**.
2. Choose **Certify an integration**.
3. Choose **Configure a connector**.
4. Select the workspace where the bidder will run.
5. Choose **Ad demand** for the connection purpose.

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

## Enter the connection details

Use the controlled fields in the form. Do not create provider names, protocols, or operations by typing values that are not in the list.

1. Select **IAB OpenRTB 2.6** under **Standards and platform contracts**.
2. Enter the secure HTTPS bidder endpoint.
3. Select the data flow that the bidder uses.
4. Select **DSP and exchange demand** as the delivery capability.
5. Select **Audio**, **Video**, or both.
6. Select the allowed markets.
7. Enter the managed request limit and response timeout for the bidder contract.
8. Select how bidder records match Podigee records.
9. Select the stored credential reference.
10. Confirm the seller and supply-chain identity for this connection.
11. Confirm the operator responsibility and authorization statements.
12. Apply the connector configuration.

The request limit, timeout, retry profile, and circuit-breaker settings are part of the managed provider profile. They protect request-time delivery. They do not change the provider's contract or guarantee that a bidder will answer.

## Verify the request mapping

Before you certify the bidder, inspect the request mapping for one test opportunity. The mapping must preserve the information needed to make and audit the auction:

* the Podigee workspace, release, opportunity, and exact Flight version;
* the delivery destination and media kind;
* the break position and available duration;
* the market and allowed content categories;
* the privacy and consent state;
* the currency, floor, fee, and price model;
* the seller identity and supply-chain nodes;
* the request identifier and time limits; and
* the provider operation and adapter version.

The request must not include raw identity, credentials, or fields that the provider contract does not allow. A change to the mapping requires a new connector version and new evidence.

## Test bid and no-bid behavior

1. Open the connector version in **Monetization > Integrations**.
2. Start the local auction conformance check.
3. Review the request and confirm the seller and supply-chain fields.
4. Run a valid bid fixture.
5. Run a no-bid fixture.
6. Run an invalid, expired, and late bid fixture.
7. Confirm the bid price and currency are valid for the Flight and demand policy.
8. Confirm the media and tracking result is valid for the selected audio or video delivery.
9. Confirm that the response does not change the original request identity.
10. Save the conformance evidence.

Local conformance uses managed test responses. It does not contact the bidder. Provider certification is a separate check that uses the partner endpoint, its contract, and its approved evidence.

The result must distinguish these outcomes:

* **Bid:** the response is valid, eligible, and can compete under policy.
* **No-bid:** the bidder did not offer an ad. This is not an error.
* **Rejected:** the response arrived, but Podigee could not use it because of price, currency, media, privacy, tracking, identity, or policy rules.
* **Expired:** the bid was no longer valid when Podigee evaluated it.
* **Timeout:** the bidder did not answer within the managed limit.
* **Transport failure:** the request could not reach the bidder or the response could not be read.

Only a selected and qualified result can become a delivery or revenue record. A bid, no-bid, or provider request alone is not billable evidence.

## Review demand policy

The active demand policy decides when the OpenRTB source may compete, what minimum CPM applies, how long Podigee waits, and what happens after no-bid, timeout, or rejection.

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

Review **Monetization > Monetization settings > Revenue and data rules** before activation. Confirm the source order, minimum CPM, currency, response limit, retry behavior, and no-fill outcome.

## Certify notices and billing evidence

An OpenRTB auction needs more than a bid response. The provider contract and release authority must define how Podigee handles the result after the auction:

* the win or loss outcome;
* the billing or clearing price;
* the impression and delivery notices;
* the error or rejection notice;
* the provider request and response identifiers;
* the expiration and replay rules; and
* the evidence needed to reconcile provider and Podigee records.

Podigee must sign and retain the request translation and the complete notice lifecycle as one versioned authority. If that lifecycle is not certified for the provider, keep the source in testing or quarantine. Do not activate a source only because the bidder returns a syntactically valid bid.

## Activate the source

1. Add the provider certification evidence to the connector version.
2. Confirm the exact provider version, endpoint, credential reference, and media capabilities.
3. Confirm that the seller and supply-chain identities are current.
4. Confirm that the certification has not expired.
5. Confirm that request, bid, no-bid, notice, billing, privacy, and fallback checks passed.
6. Select the environment where the source may run.
7. Submit the connector for the required review policy.
8. Activate the connector only when the review, certification, and release state are current.
9. Open **Monetization > Campaigns** and choose **Add flight**.
10. Select **Connected demand provider**.
11. Select the certified provider, the OpenRTB protocol, and the certified auction operation.
12. Save the Flight and continue through the normal proposal, review, approval, and publication flow.

If the provider, protocol, or auction operation does not appear, do not enter it by hand. The connection is not ready for that use, or the workspace does not have the required authority.

## Understand request-time behavior

For an eligible RSS audio request, Podigee checks the episode, break, listener context, Flight, market, policy, and OpenRTB connection. It sends an auction only when the source is next in policy order. It validates the result, selects the ad, tries the next eligible source, or uses the configured clean or house fallback.

For an eligible HLS video request, Podigee checks the video presentation, break duration, player capability, Flight, policy, and OpenRTB connection. It validates the bid, media, tracking, price, currency, and notice result before it places the ad in the HLS presentation.

The selected result, delivery evidence, and qualified revenue record must refer to the same request and exact connector version. An auction response is not proof that the player completed the ad.

## If the bidder fails

* **No connection appears:** confirm that the connector is active and has current certification.
* **The bidder is not selectable in Add flight:** confirm its media, destination, protocol, and auction operation capabilities.
* **The seller or supply-chain identity fails:** repair the identity version and create a new connector version. Do not edit historical auction evidence.
* **The response times out:** review the managed timeout and latency evidence. The request continues to the next eligible source or fallback.
* **The bid is rejected:** review the exact price, currency, media, consent, notice, or policy reason.
* **A notice is missing or ambiguous:** keep the source inactive and reconcile the provider contract before retrying.
* **The source is quarantined:** repair the provider version, run conformance again, and submit new evidence.
* **There is no qualified demand:** use the configured next source, house Flight, or clean content. Do not create paid evidence for an unqualified bid.

Use **Monetization > Operations** for the auction diagnostic. It preserves the original request and response and reports the exact mapping, bid, notice, or lifecycle failure.

## Expected result

The OpenRTB source is active only for the certified provider version, seller identity, supply-chain identity, markets, media types, auction operation, and release authority that passed the checks. An eligible listener or player receives a validated ad or the declared fallback. Campaign, auction, decision, delivery, measurement, and revenue evidence 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/connect-an-openrtb-demand-source.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.
