> 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/register-an-owned-player-or-delivery-surface.md).

# Register an owned player or delivery surface

Register an owned player or delivery surface, verify media and measurement behavior, and switch only after the recovery path is ready.

Register a player or delivery surface when your team controls the app, player, media route, or stream that will request Podigee Ad Server delivery. The registration defines the audio and video behavior, listener measurement, privacy mode, and safe fallback for that surface.

An active connector is not enough. The surface must pass its media, request, measurement, and recovery checks before it can receive paid ads.

## Before you start

* You have permission to configure and activate integrations.
* You know the podcast, app, or player that will use the surface.
* The player can request the declared audio or video route.
* The player can send the required signed playback events.
* You have a clean-content fallback and a contact for incident response.
* The connector uses a secure endpoint and an approved credential reference.

For an owned player, prepare the player identity, supported media, playback session identity, request headers, event names, and fallback behavior before you start.

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

## Register the surface

1. Open **Monetization > Integrations**.
2. Select **Certify an integration**.
3. Choose **Configure a connector**.
4. Select the workspace and the podcast or delivery scope.
5. Select **Owned player** as the delivery capability.
6. Select **Audio and video** or the media kind that the player supports.
7. Enter the secure endpoint without embedded credentials.
8. Select the data flow and allowed markets.
9. Select the traffic limit, response timeout, record matching method, and fallback profile.
10. Add the standards and platform contracts that the player must pass.
11. Add the player identity and credential reference through the approved secure process.
12. Submit the connector for verification.

Podigee chooses the owned-player conformance suite from the selected capability. The form uses controlled values for media, markets, standards, limits, and identity handling. If a required option is missing, do not enter a similar value as free text.

## Verify the player

1. Open the new connector from **Monetization > Integrations**.
2. Run the owned-player conformance check.
3. Request an audio and a video test when both media kinds are enabled.
4. Confirm that the player receives the expected media and ad decision.
5. Confirm that the player sends one valid start event and the required progress or completion events.
6. Confirm that repeated, delayed, or unsigned events are rejected or ignored as defined by the contract.
7. Confirm that a no-fill or provider failure serves the selected safe fallback.
8. Save the verification result and review every failed check.

Playback or media delivery alone does not prove a qualified impression. Podigee correlates the player event with the exact delivery decision before it counts a result as qualified.

## Prepare the podcast delivery switch

Use the **Delivery portfolio** on the Integrations page to select the podcasts that the new delivery system may prepare. Bulk preparation copies and checks media. It does not change a public media URL or switch live delivery.

For each selected podcast, review **Podcast delivery** and confirm these checks:

* The podcast and Monetization workspace are bound.
* Clean episode masters are ready.
* The delivery package is complete and verified.
* Every affected episode is prepared.
* Listener measurement is protected.
* The existing delivery has a verified recovery path.
* Public media routes are verified.
* The switch operation has a planned boundary and a saved recovery point.

Resolve every blocker before you switch. A podcast can remain on the existing Podigee delivery while the new surface is prepared and tested.

## Activate the surface

1. Open the connector state and review the latest verification evidence.
2. Confirm that the exact player identity, media kind, endpoint, and fallback are still current.
3. Select the activation action.
4. Choose the environment and effective time.
5. Confirm the activation.
6. Check the active state and the first delivery evidence in **Operations**.

Activation changes the allowed delivery authority. It does not rewrite earlier listener or revenue records. Keep the previous route ready until the new route has a verified recovery point.

## Monitor the surface

Review **Monetization > Evidence & Money** for delivery, qualified measurement, and fallback results. Review **Monetization > Operations** for timeouts, event failures, route errors, and recovery actions.

Investigate a missing qualified result in this order:

1. Confirm that the player requested the correct route.
2. Confirm that the delivery decision exists for the playback session.
3. Confirm that the player event is signed and linked to that session.
4. Confirm that the event was not duplicated or outside the allowed time window.
5. Confirm that the selected fallback is visible in the delivery record.

## Suspend or replace the surface

Suspend the surface when it must stop receiving new paid delivery but its history is still needed. Create a new connector version when the player identity, endpoint, media, event contract, or fallback changes. Keep the prior version and its evidence for audit and recovery.

## If a check fails

* **Player identity is not accepted:** use the registered identity and current credential reference.
* **Media check fails:** prepare the declared audio or video variant and test it again.
* **Event check fails:** compare the player event with the current measurement contract.
* **Fallback check fails:** select an approved clean-content or house fallback.
* **Route check fails:** keep the existing delivery active and repair the route before activation.
* **Recovery check fails:** create a verified recovery point before requesting a switch.

## Expected result

The owned player or delivery surface has a current, versioned capability with verified media, measurement, privacy, fallback, and recovery behavior. The surface can receive paid ads only when the exact capability is active, and operators can return to the previous route without losing the delivery history.


---

# 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/register-an-owned-player-or-delivery-surface.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.
