> 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/repair-a-failed-external-synchronization.md). # Repair a failed external synchronization Repair a failed connection to an external system without sending the same change twice. Podigee Audio Video Ad Server helps you repair a failed synchronization with an external system. After the first mention, this article uses Podigee Ad Server for the product name. Use this task when a connected system has a different state from Podigee, or when a synchronization attempt stopped before it received a clear result. The repair keeps the original integration version and request evidence. It does not edit a saved integration or silently create a second external record. ## Before you start * You have permission to manage integrations in the workspace. * The integration has a recorded failure, uncertain result, or reconciliation conflict. * You can check the related record in the external system. * You have the external receipt or request reference when the external system accepted the change. * You know the owner of the integration and the expected final state. Do not retry an uncertain request only because no receipt is visible. First check the external system and the latest attempt in Podigee. ## Find the failed synchronization 1. Open **Monetization > Operations**. 2. Filter the list to connection or integration issues. 3. Open the issue that names the affected connection and record. 4. Review the impact, current state, latest attempt, and available evidence. 5. Confirm that the issue belongs to the integration that you intend to repair. ![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) *Start with the issue that has the highest listener or revenue impact.* Review the request reference, external identity, integration version, and failure reason before you start a repair. These values identify the exact synchronization. They do not change when you open the repair form. ## Choose a repair action 1. Choose **Repair synchronization** from the issue or integration workflow. 2. Confirm the selected integration version and external record. 3. Choose one action: * **Reconcile:** use this when the external system completed the request but Podigee did not record the result. Enter or select the external receipt when one is available. * **Retry:** use this when the failure is temporary and the external system did not accept the request. Repair the provider condition before you retry. * **Supersede:** use this when the external record is no longer the correct identity and the integration owner has approved a replacement path. 4. Confirm the request reference and the reason for the action. 5. Submit the repair. The repair runs as an operation. Podigee returns an operation status first and records the result when the synchronization worker finishes. A submitted repair is not proof that the external system accepted the change. ![The current One Podigee issue workflow asks for a controlled cause and an evidence-based diagnosis.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-a9f80eb5fedcde86fd0a404472823fb142391397%2Fdoc-monetization-067-diagnosis-form.png?alt=media) *Use the controlled cause and the evidence note to explain why you chose the repair action.* ## Check the result 1. Open the operation receipt from the issue or from **Monetization > Operations**. 2. Confirm the integration version, external identity, action, and request reference. 3. Check the final synchronization state. 4. Check the external receipt or response reference when the provider returned one. 5. Confirm that the operation created one repair attempt and one result event. 6. Open the connected system and verify the final state there. A successful repair shows an in-sync state and a receipt that links the local attempt to the external result. A retryable failure keeps the issue open and gives you a next attempt time. An ambiguous or conflict state keeps the affected integration protected until an owner resolves the identity or provider result. A terminal failure needs a new correction or an owner decision. ![The current One Podigee safe-response dialog explains that new paid decisions can pause while existing podcast delivery remains available.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-2cc8e19df6ec3ed26d22498a37a399c5f393a7b8%2Fdoc-monetization-067-apply-confirmation.png?alt=media) *Use the protected response when continuing could create a second paid or external effect.* ## Recover safely * **The provider accepted the request, but Podigee shows no receipt:** choose **Reconcile** and provide the provider receipt. Do not choose **Retry**. * **The provider did not receive the request:** repair the provider connection, then choose **Retry** with the same request reference. * **The external identity is ambiguous:** stop the repair and ask the integration owner to confirm the correct record. Do not create a new identity to hide the conflict. * **The integration version is stale:** return to the current integration workflow. Do not edit the old version in place. * **The integration is retired:** create or activate an approved successor. A retired integration cannot be repaired. * **The issue remains after a successful provider response:** keep the integration protected and open the receipt and evidence records for the support owner. Do not submit the same repair with a new request reference. Reusing the original reference lets Podigee return the original result when the provider already accepted the request. ## Expected result The external state and the Podigee state agree, or the issue remains clearly identified for the next owner. The repair preserves the original integration version, request evidence, external receipt, attempt history, and operation receipt. A provider timeout or missing callback does not create a duplicate external record, duplicate delivery, or duplicate money effect. ## Next useful task If the repair returns an in-sync state, run the relevant conformance check before you activate a new integration version. If the issue remains open, use the operation receipt and evidence records when you contact the integration owner or support team. --- # 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/repair-a-failed-external-synchronization.md?ask=&goal= ``` `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.