> 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/export-portable-state-and-evidence.md).

# Export portable state and evidence

Export selected Podigee Ad Server records as a signed, machine-readable portability package.

Podigee Audio Video Ad Server can create a signed package for a migration, handover, audit, or customer departure. The package contains the selected current records and their provenance. It does not change live delivery, campaign state, or source media masters.

Use this task when another system needs a controlled copy of Podigee data. Use the smallest export profile that meets the receiving system's need. A complete workspace export is useful for a full handover, but it contains more records to review.

## Before you start

* You have permission to export portability data for the selected workspace.
* You know the workspace and the receiving system or person.
* You know which data the receiving system needs.
* You have a recipient public key or an approved key handoff. Podigee uses the key digest to bind the package to its intended recipient.
* You know how the receiving system will verify the package signature and digest.
* Your workspace review rules allow the export. This command does not require a second reviewer by default, but a local policy can require one.

An export is a copy of saved versions. It is not a live connection to the workspace. Later changes in Podigee do not change a package that was already created.

## Choose an export profile

Open **Monetization > Revenue jobs > Migration and portability** and choose the portability export action. Select one profile:

* **Complete workspace** includes the full set of portable workspace, campaign, inventory, creative, policy, delivery, evidence, finance, and audit records.
* **Campaign operations only** includes the records needed to continue campaign operations in another system.
* **Evidence and finance only** includes delivery evidence, reports, invoices, settlements, payouts, and the related measurement definitions.

![The current One Podigee Revenue jobs page shows guided work such as commercial context, policies, inventory, and editorial ad breaks.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-0cf33f037b414e6d8ee7a4b1eeb843c73115bd0a%2Fdoc-monetization-068-revenue-jobs.png?alt=media)

*Choose the job family that describes the result you need.*

## Review the package scope

Before you start the export, review:

* The selected workspace.
* The selected export profile.
* The record types included by that profile.
* The current saved version of each record.
* The recipient key handoff.
* An optional **Download expires** time.

Podigee selects one current saved version for each included record. It records the record type, record ID, version ID, revision, and content digest. If a record changes after this review, the package still uses the version selected when the export starts.

Keep the expiry in place when the package is shared through a temporary handoff. Choose no expiry only when the receiving system stores the package in a controlled location with its own access rules.

## Start the export

1. Select the export profile.
2. Confirm the workspace and scope.
3. Confirm the recipient key handoff.
4. Set an optional expiry time.
5. Review the package contents and access rule.
6. Select **Start**.

Podigee starts the export as background work. You can leave the page and return to the operation later. The command is safe to retry with the same request. A repeated request with the same saved versions returns the original result instead of creating a conflicting package.

## Download and verify the package

When the operation is complete:

1. Open the operation result.
2. Select **Download package**.
3. Save the package in a restricted location.
4. Verify the package signature with the published Podigee verification key.
5. Verify the package digest and the manifest digest.
6. Check the schema version, export profile, scope, record count, and expiry.
7. Compare a sample of record IDs, version IDs, revisions, and digests with the request.
8. Give the package and its verification result to the receiving system.

The result shows the package URI, package digest, package size, manifest digest, signature key ID, and source version count. The interface uses shortened references for long IDs. Copy the full value only when the receiving system asks for it.

## What the package contains

The signed manifest identifies:

* The package schema version and package ID.
* The workspace and export scope.
* The selected export profile.
* The recipient key digest.
* The expiry, when one was set.
* Every included record's type, ID, version, revision, and content digest.
* The signature and the key ID used to verify it.

The package preserves source media lineage. It does not write stitched ads into source masters. A receiving system can therefore import the records and prepare its own delivery outputs without changing the original media source.

## If Podigee blocks the export

* **You do not have permission:** ask a workspace administrator to grant the portability export permission or to run the export.
* **The selected record is unavailable:** choose a current record in the selected workspace.
* **The package is too large:** choose a narrower profile or a smaller workspace scope.
* **The expiry has passed:** choose a future expiry time.
* **The recipient key is invalid:** use the approved public key handoff again.
* **A record changed while the form was open:** reopen the export action and review the current versions.
* **The operation fails:** keep the original operation result and retry with the same request after the displayed problem is resolved.

Do not edit the package, manifest, or digest by hand. Create a new export when the scope or records must change.

## Complete the handover

After the receiving system confirms the package:

1. Keep the package verification result with the export receipt.
2. Record who received the package and when.
3. Confirm that the package is stored under the agreed retention rule.
4. Remove temporary copies after the handoff period ends.
5. Keep the Podigee operation and audit record according to your workspace retention policy.

If the receiving system reports a mismatch, stop the import. Compare the package digest and the record version references first. Do not repair a mismatch by changing the package.

## Expected result

The receiving system has a scoped, signed, and verifiable package of Podigee records. The package has clear provenance and an optional expiry. Live delivery, analytics, finance records, and source media masters remain unchanged.

## Next useful tasks

Use [Plan a safe migration](/documentation/grow-and-monetize/monetization/plan-a-safe-migration.md) when the package will support a move to another delivery system. Use [Reconstruct and export audit evidence](/documentation/grow-and-monetize/monetization/reconstruct-and-export-audit-evidence.md) when the receiving party needs a focused incident or audit package instead of workspace state.


---

# 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/export-portable-state-and-evidence.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.
