> 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/fix-a-vast-openrtb-or-cats-provider-problem.md).

# Fix a VAST, OpenRTB, or CATS provider problem

Repair or safely suspend a VAST, OpenRTB, or CATS demand source when the provider fails, returns an unsafe response, or cannot serve the selected delivery path.

Use this guide when a connected demand provider times out, returns no-fill, fails validation, or is not available for a Flight. The provider response is only one input to the decision. Podigee must validate it before it can serve or qualify the result.

## Identify the protocol and source version

Open **Monetization > Integrations** and select the provider connection. Record the short provider reference, protocol, operation, media, markets, and capability state.

| Protocol | Main response                            | Typical failure                                                    |
| -------- | ---------------------------------------- | ------------------------------------------------------------------ |
| VAST     | Playable media and tracking instructions | Invalid XML, wrapper loop, unsafe redirect, or incompatible media. |
| OpenRTB  | Bid, no-bid, or auction response         | Invalid bid, timeout, price or media mismatch.                     |
| CATS     | Supported demand result or no-fill       | Contract mismatch, unsupported capability, or provider rejection.  |

The selected protocol and operation come from the certified connection. Do not type an unknown provider or operation into a Flight.

![The current 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)

*A provider must be selectable from a current certified connection.*

## Read the failure category

Open **Monetization > Operations** and select the provider diagnostic. Read the first failure category and the provider version that produced it.

| Failure                             | Meaning                                                                     | Safe action                                                                 |
| ----------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| Credential or authorization failure | Podigee cannot authenticate the configured connection.                      | Repair the stored credential reference. Never paste a secret into the form. |
| Rate limit                          | The provider rejected the request volume.                                   | Respect the retry boundary and review the configured request limit.         |
| Timeout                             | The provider did not respond within the contract limit.                     | Let the request use the next source or fallback. Check provider latency.    |
| Unsafe or invalid response          | The response fails XML, JSON, media, tracking, or security checks.          | Keep it out of delivery and send the redacted failure to the provider.      |
| Wrapper loop or redirect limit      | The response exceeds the managed wrapper or redirect boundary.              | Ask the provider to shorten the response chain.                             |
| Unsupported capability              | The source cannot serve the requested media, destination, or operation.     | Select a certified capability or use another source.                        |
| Stale mapping                       | The provider or operation no longer matches the current connection version. | Bind the Flight to the current certified capability.                        |
| Provider rejection                  | The provider rejected the request for its own policy or contract reason.    | Read the provider reason and escalate when it is not correct.               |

Do not call a provider error a no-fill without reading the stored result. A timeout or invalid response can be a delivery incident even when the configured fallback is safe.

## Check demand order and fallback

Open **Monetization settings > Revenue and data rules** and confirm:

* source order;
* minimum CPM or price boundary;
* response limit and timeout;
* retry behavior;
* next eligible source;
* house or clean no-fill fallback.

![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 policy decides what happens after a provider failure.*

Do not raise the provider priority or lower the price only to hide a failure. Change demand rules only when the commercial policy is wrong and the change is approved.

## Retry one safe operation

Retry only when the diagnostic says that the operation is retryable:

1. Confirm that the provider endpoint is healthy.
2. Confirm that the stored credential is current.
3. Confirm that the connection version is still active.
4. Select the displayed retry action once.
5. Wait for the result.
6. Confirm the provider response and the Podigee decision separately.

Do not retry a malware, unsafe response, invalid media, or wrapper-loop result without a corrected provider response. Do not submit the same request repeatedly during a rate limit or timeout.

## Repair a credential problem

Use the workspace's stored credential reference. Check its owner, scope, expiration, and allowed endpoint. Rotate the credential through the secure credential workflow when it is expired or revoked.

After rotation:

1. Create a new connector version if the connection is versioned.
2. Run the managed conformance check.
3. Confirm that the provider returns the expected test result.
4. Complete the configured review.
5. Activate the new connector version.
6. Confirm that the Flight can select the new certified operation.

Keep the old connector evidence. Do not edit its historical payload or credential reference.

## Repair a media or response problem

Read the redacted response evidence. Confirm the provider returned:

* a supported media type and duration;
* the correct audio or video format;
* valid tracking and error events;
* safe URLs and redirect behavior;
* the expected advertiser or content category;
* the required price, currency, and auction fields;
* no private identity or credential data in the response.

Ask the provider to correct the response, then run conformance again. Keep the source quarantined until the corrected version passes.

## Fix an unsupported capability or stale mapping

If the provider does not appear in **Add flight**, check the capability state, media, destination, authority period, and provider version. A current connection can still be unavailable for one operation.

1. Open the connection capability details.
2. Confirm the selected destination and media type.
3. Confirm that certification has not expired.
4. Select the current provider operation in the Flight form.
5. Run Campaign checks again.

Do not copy a provider ID or operation from an older Flight. A stale mapping can point to a withdrawn or uncertified capability.

## Inspect the decision after a provider attempt

Open **Evidence & Money > Live ad delivery > Recent ad decisions**. Confirm:

* provider, protocol, and operation;
* result, reason, and fallback;
* selected Creative when there is a fill;
* delivery method and content context;
* measurement and qualified value.

A provider bid, accepted request, or playable URL is not a Podigee delivery event. Qualification requires the decision and measurement contract to pass.

## Suspend the source when it can affect delivery

Suspend or quarantine the provider when repeated failures could produce unsafe media, wrong ads, invalid tracking, or a large no-fill increase. Keep the configured next source or clean fallback available.

Notify the provider with the short connection and operation references, failure category, response time, and redacted evidence. Do not send credentials, listener identity, or full private payloads.

## Confirm recovery

After one corrected conformance run and one representative test request:

* the connection is active for the intended capability;
* the provider response passes validation;
* the Flight can select the current operation;
* the decision shows the expected provider and result;
* fallback is used when the provider fails;
* no false delivery or revenue event was created.

If the provider remains unhealthy, keep it suspended and use the next eligible source. Do not re-enable it only because the endpoint responds to a health check.

## Expected result

The provider is active only for a certified version and supported capability. A valid response can compete, an invalid or unsafe response is rejected, and a timeout or provider failure follows the declared fallback. Provider, decision, delivery, analytics, and money evidence remain separate and traceable.


---

# 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/fix-a-vast-openrtb-or-cats-provider-problem.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.