What does one stamp call return?

The stamped file with the manifest embedded, a proof URL for the public record, and a binding field of either manifest+registry or registry_only so you always know which you got. Stamping is synchronous — there are no webhooks to wire up.

Which formats can you sign?

PNG, JPEG, WebP, GIF and TIFF get the full stamp: embedded Content Credentials plus the registry record. BMP and ICO fall back to a registry-only record. Anything unsupported returns HTTP 415 with a machine-readable code and the supported list, never a bare 400. Limit is 10 MB per file.

Do you support audio and video?

No, and we will not claim it before it ships. c2pa-rs can embed manifests into MP4 and MOV, but our fingerprint is not yet perceptually robust for time-based media, which would mean a soft binding that quietly fails. The API shape is reserved for it.

Median 41 ms, 53 ms at p99, measured over loopback and excluding network time. Your figures will depend on where you call from and how large the content is.

Is retrying a stamp safe?

Yes. Pass an Idempotency-Key header and a retry returns the original proof rather than creating a duplicate record — which matters because the transparency log is append-only, so a duplicate could never be cleaned up later.

C2PA Signing as a Service

What you would build yourself

Worth pricing honestly before deciding to buy. Producing your own Content Credentials at production volume means owning all of this:

A trusted certificate. Sourced from a CA whose chain validators accept, then renewed and revoked on schedule.
Key custody. Private keys in an HSM or KMS, with access controls that hold up in an audit.
Manifest construction. Assertions, claim hashes, and format-specific embedding for every type you serve — see c2pa-rs for how much surface that is.
The stripping problem. None of the above keeps the manifest attached once a platform re-encodes the file.

What one call looks like instead

import { readFile, writeFile } from "node:fs/promises";
import { Zerobyte } from "zerobyte";

const zb = new Zerobyte({ apiKey: "0b_key_..." });

const result = await zb.stamp({
  content: await readFile("art.png"),
  contentType: "image/png",
  provider: "acme-ai",
  model: "imagen-x",
});

console.log(result.binding);  // "manifest+registry"
if (result.stampedBytes) await writeFile("art.stamped.png", result.stampedBytes);

Your brand is named as the claim generator, so the credential reads “generated by you” even though we hold the key. Full details in the stamp endpoint reference.

Formats, limits, and what we don't claim

Full stamping needs both halves to work: c2pa-rs must embed the manifest, and we must be able to fingerprint the content. Where only one half works, the response says so rather than degrading silently.

Full stamp — PNG, JPEG, WebP, GIF (fingerprinted on the first frame) and TIFF. Embedded manifest plus registry record.
Registry only — BMP and ICO. A fingerprint record and a proof, with no embedded manifest, and binding set accordingly.
Not supported, not claimed — audio, video, PDF and text. These return 415 with a machine-readable code and the supported list.
Size — 10 MB per file. One caveat we publish rather than hide: a small region cut out of a much larger image reads as different content, so trimmed edges and screenshots match while cropped-out details do not yet.

Managed certificate, or bring your own

Managed is the default and the reason most teams arrive here. Bring-your-own is on the roadmap for teams that need the signing identity to be provably theirs; the API shape does not change when you switch, only the signing identity does.

One thing to know up front

Our certificate is still going through the C2PA Conformance Program, so validators currently read a stamped manifest as structurally valid while noting the signer is not yet on the public trust list. The certificate page covers what that means in practice.

Verification is free, and not just for our own files

A provenance registry only works if checking it costs nothing, so verification is free forever, needs no account and no API key, and is CORS-enabled. It reads Content Credentials from any signer — not only ours — and matches fingerprints against the public registry, then returns a verdict built from that evidence with every signal disclosed separately. Never a probability.

You can also recompute an inclusion proof yourself against a published, Ed25519-signed tree head, in about twenty lines. Trust the math rather than us.

Common questions

What does one stamp call return?: The stamped file with the manifest embedded, a proof URL for the public record, and a binding field of either manifest+registry or registry_only so you always know which you got. Stamping is synchronous — there are no webhooks to wire up.
Which formats can you sign?: PNG, JPEG, WebP, GIF and TIFF get the full stamp: embedded Content Credentials plus the registry record. BMP and ICO fall back to a registry-only record. Anything unsupported returns HTTP 415 with a machine-readable code and the supported list, never a bare 400. Limit is 10 MB per file.
Do you support audio and video?: No, and we will not claim it before it ships. c2pa-rs can embed manifests into MP4 and MOV, but our fingerprint is not yet perceptually robust for time-based media, which would mean a soft binding that quietly fails. The API shape is reserved for it.
How fast is a stamp?: Median 41 ms, 53 ms at p99, measured over loopback and excluding network time. Your figures will depend on where you call from and how large the content is.
Is retrying a stamp safe?: Yes. Pass an Idempotency-Key header and a retry returns the original proof rather than creating a duplicate record — which matters because the transparency log is append-only, so a duplicate could never be cleaned up later.

Ready to put credentials on your own output?

No certificate to procure, no spec to learn. Verification stays free for everyone, forever.

Start with the SDK Join Waitlist