Choosing a video API? Ask for evidence in the actual export.
A procurement and acceptance protocol for provenance across generation endpoints, formats and delivery paths.
The short answer
Evaluate provenance on an API's actual delivered output, not its product description. Record the endpoint, model or service version, output format and processing steps. Inspect that file and any client-facing derivative. A provider-level C2PA claim does not establish credential presence or validation for every endpoint and export.
Source context: Official c2pa-web reader API. The workflow recommendations below are editorial analysis.
Evaluate the endpoint, not the headline
A service can expose several models, export formats and download routes. A general statement that it supports provenance is not enough to evaluate the precise integration you will ship. Ask for a sample from the exact endpoint, output type and account tier you intend to use. Keep that sample with the vendor’s written explanation of its expected metadata.
Do not compare vendors by recognizable issuer strings alone. A gateway, model provider and processing service may occupy different positions in the delivery chain. Your acceptance document should explain which party made which declaration and which evidence you independently inspected.
Create a small acceptance contract
List the observations your application requires: a supported playable file, an embedded record when promised, the expected type of declaration and a documented way to handle failures. Record the actual reader result instead of treating a non-empty JSON object as success. A response can be structured and still report validation issues.
Make error behavior part of the contract. What happens if the generation succeeds but the download is partial? What if a retry returns a new file? What if the provider changes an export route? Keep provider request identifiers in your private operational system, and avoid publishing signed download URLs or customer prompts in a public provenance report.
Test the full downstream path
Run your sample through the same downloader, editor and transfer process your users will use. Save intermediate copies only where permitted. Inspect each transformation, because a pristine vendor output does not prove that your final deliverable retains its credentials. This is an integration test of your own workflow, not a claim about every output the vendor might generate.
When upgrading an SDK or switching models, re-run the acceptance pack. Write the observed date and version in the result so future maintainers know what was actually tested. If the evidence does not satisfy the procurement requirement, ask the vendor for clarification rather than adding a local declaration that pretends to come from the original provider.
A comparison for your review
| Acceptance item | Ask the provider | Verify yourself |
|---|---|---|
| Output route | Which endpoint and format? | Inspect a real permitted sample |
| Provenance claim | Who signs what? | Read the actual assertions |
| Change management | How are changes announced? | Re-run a retained test pack |
Put it into practice
- Request a sample from the actual integration path.
- Define success and failure states explicitly.
- Keep private request data out of public reports.
- Test the final delivery, not just provider output.
- Repeat after endpoint and SDK changes.
Bring your own evidence.
Inspect a local file and see what it actually declares.