> 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/suspend-an-integration.md).

# Suspend an integration

Stop selected capabilities on a connected system while protecting active delivery and preserving evidence.

Podigee Audio Video Ad Server lets you suspend selected capabilities on a connected external system. After the first mention, this article uses Podigee Ad Server for the product name. Use a suspension when a provider, credential, route, or platform capability is unsafe or unavailable.

Suspension is a controlled stop. It does not delete the integration, change its saved version, or remove its history. Other capabilities can remain active when you select only the affected capabilities.

## Before you start

* You have permission to activate and suspend integrations in the workspace.
* You know which integration version and capabilities are affected.
* You know the reason for the suspension and the owner who will resolve it.
* You understand the configured fallback for the affected traffic.
* You know whether the suspension must start now or at a future time.

Check the provider and the latest evidence before you suspend. Use a suspension to stop unsafe new activity, not to hide an uncertain result.

## Review the integration health

1. Open **Monetization > Operations**.
2. Review open integration issues, delivery issues, incidents, and recovery work.
3. Open the issue or integration record that needs protection.
4. Confirm the selected integration version, capabilities, current state, and latest evidence.
5. Confirm the response owner and the expected fallback.

![The current One Podigee Operations page shows one high-impact delivery issue, current incidents, recovery work, and delayed evidence receipts.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-6db53133b0902c0ebe2d348da5710f6f8cfe7c7b%2Fdoc-monetization-067-operations.png?alt=media)

*Review the impact and recovery work before you stop a capability.*

## Create the suspension

1. Open the integration workflow for the selected connection.
2. Choose **Suspend integration**.
3. Select the capabilities that must stop.
4. Select the operational reason.
5. Choose an effective time.
6. Review the selected integration version, capabilities, reason, and effective time.
7. Confirm the suspension.

The form accepts a current time or a future time. A suspension does not use an automatic end time. Create a new certified activation workflow when you want the capability to return.

Your workspace review rule controls the confirmation path. A solo workspace can use a direct confirmation. A workspace with optional review can ask another person to check the action. A workspace with enforced independent review must receive that approval before the suspension takes effect.

## Understand the effect

The result shows the exact capabilities that stopped and any capabilities that remain active. Affected new requests use the configured fallback for that integration. The fallback can preserve an existing certified route, use another approved demand or delivery path, or keep the capability disabled. Existing playback or an already assigned presentation follows its recorded safety and expiry rules.

Open the command receipt in **Monetization > Operations** and check:

* the integration version;
* the selected capabilities;
* the reason and effective time;
* the resulting integration state;
* the remaining active capabilities;
* the receipt and event references.

The suspension changes authority through one recorded command. It does not mutate an older integration version or create a second version with hidden changes.

## Work after the suspension

1. Tell the integration owner which capabilities stopped and when.
2. Check that new requests follow the expected fallback.
3. Monitor delivery, no-fill, and revenue evidence for the affected scope.
4. Keep the integration suspended while the provider, credential, route, or platform issue is unresolved.
5. Record the repair evidence when the owner confirms that the cause is fixed.

Do not activate the integration again only because the provider endpoint responds. Run the required conformance checks and confirm the exact certified version first.

## If the suspension fails

* **The integration is not active, degraded, or certified:** resolve the earlier state first. The suspension command cannot stop an integration that is not in a suspendable state.
* **A capability is not available on the integration:** select only capabilities declared by the selected integration version.
* **The effective time is invalid:** use a valid current or future date and time.
* **The workspace requires another reviewer:** open the exact suspension request and complete the required review. Do not create a second request.
* **The fallback is not ready:** keep the affected capability disabled and repair or certify the fallback before activation.
* **The result is unclear:** use the command receipt and operation history. Retry the same command with the same request key only after you confirm that the first command did not complete.

## Expected result

The selected integration capabilities are suspended at the recorded time. New activity follows the declared fallback, remaining capabilities stay active when allowed, and existing playback keeps its recorded safety rules. The workspace retains the exact version, reason, actor, review evidence, and command receipt needed to repair and activate the integration later.

## Next useful task

When the cause is fixed, use **Repair a failed external synchronization** for a provider state that does not agree with Podigee. Then run the relevant conformance check and activate a new certified integration version.


---

# 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/suspend-an-integration.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.