Build with 0byte

0byte is a managed C2PA signing service: origin proofs for AI content that survive screenshots, re-encoding, and stripped metadata. Two verbs cover the flow:

• Stamp — at generation, embed a signed C2PA manifest (Content Credentials) in the file and anchor a derived perceptual fingerprint in a public, append-only transparency log. Your brand goes in the manifest.
• Verify — check any content, free and without a key. It reads standard Content Credentials from any signer — not just 0byte's — and matches fingerprints against the registry. The verdict is built from that evidence, never from a model's guess.

Install an SDK (or use plain HTTP — the API is the contract):

Stamp a generation, publish the stamped file, and verify anything later:

Get a key from your terminal — pip install zerobyte && zerobyte login opens a browser approval and hands the key to your CLI. It is the only way keys are minted; the dashboard and /v1/keys list and revoke. Stamp and key-management requests then authenticate with a bearer token:

Keys carry scopes, and each authenticated endpoint requires one: stamp for stamping, analyze for the deprecated estimate endpoint, and keys for key management. A key without the required scope gets 403 SCOPE_DENIED.

Per API key, per minute:

Every response to a key on a rate-limited tier carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (epoch seconds at which one unit of capacity returns — the window slides over the last minute). Over the limit returns 429 RATE_LIMITED with Retry-After in seconds.

Every stamp creates two bindings at once. The C2PA manifest travels inside the file — standard Content Credentials any C2PA validator can read. The perceptual fingerprint is derived from the pixels — never embedded — and anchored in the public transparency log, so origin survives even when metadata is stripped.

The embedded manifest is standard C2PA. It names your brand as the claim generator (“generated by Acme Studios using imagen-x”), declares AI origin via the IPTC trainedAlgorithmicMedia source type, and carries an org.0byte.proof assertion that links back to the registry record.

Manifest embedding by format:

0byte matches content with perceptual hashing rather than exact byte matching. Two visually-identical images produce near-identical fingerprints, so a match holds even after JPEG re-encoding, resizing, or a screenshot — exactly the cases where embedded metadata is destroyed.

The fingerprint (version v2) is a 64-bit perceptual hash: luma → 32×32 → 2-D DCT → the top-left 8×8 low-frequency block → each coefficient compared to the median. Every proof records its fingerprint_version; only the current version takes part in matching.

Verify returns one of four verdicts, each traceable to evidence in the same response. There is no “92% AI” anywhere in a verdict — a probability is a guess, and guesses don't survive appeals.

Want an AI-likelihood estimate anyway? That's the opt-in analyze endpoint — always separate, never part of a verify verdict.

Every proof is appended to a single append-only Merkle tree (RFC 6962-style) and the signed root is republished as the tree grows — new proofs are anchored within about a minute. Anyone can fetch an inclusion proof to confirm a record was committed and never altered, and a consistency proof to confirm history was never rewritten. No blockchain — Ed25519 signatures over an append-only tree.

A thin client over the REST API — httpx + pydantic, no ML on your side.

Errors are typed and carry the API's code: catch RateLimitError (429) and the retryable VerificationUnavailableError (503); ZerobyteError is the base.

Zero-dependency client for Node and edge runtimes, fully typed.

Same typed errors as Python: RateLimitError, retryable VerificationUnavailableError, and the ZerobyteError base carrying code and status.

All endpoints live under https://api.0byte.tech and return JSON. The machine-readable contract is served at GET /v1/openapi.yaml. Within /v1 changes are additive only — existing fields never change meaning or disappear — and every addition is recorded in the changelog.

Stamping is one authenticated POST after generation, wherever your stack runs it. Each recipe below is complete: an Idempotency-Key per asset makes retries safe against the append-only log, and the response's binding field says exactly what you got — publish stamped_content when it is present.

Fetching is not verifying. This is a complete independent verifier — it checks the Ed25519 signature on the head, recomputes the leaf hash from the public proof record, and folds the Merkle audit path up to the signed root. If any line lies, an assert fails.

• Leaf hash: SHA256(0x00 ‖ proof_id ‖ fingerprint ‖ timestamp); interior nodes are domain-separated with 0x01.
• Head signature covers sth:v1:{key_id}:{tree_size}:{root_hash}, and key_id is the first 4 bytes of SHA256(public_key) — derivable, not trusted.
• The path-folding algorithm is RFC 9162 §2.1.3.2 — the same one Certificate Transparency uses.
• Key trust: deriving key_id proves the served key matches its identifier — not that it belongs to the log operator. Pin a known key, or compare /v1/transparency/keys across time to detect substitution.

The EU AI Act's transparency obligations (Article 50) require providers of generative AI systems to mark outputs as artificially generated in a machine-readable way, and for that marking to be detectable. Here is how each requirement maps to what a stamp gives you:

Errors return {"code", "message", "docs_url", "request_id"} with the matching HTTP status; 415s also carry supported, the list of media types that would have been accepted. Every response — errors included — carries an X-Request-Id header: yours, echoed, when it matches [A-Za-z0-9._-]{1,128}; otherwise a generated one. Quote it when you write in.