Developer portal
Verification as a service — and everything you need to stop needing it.
The verification API is a convenience, never a dependency
A sealed file carries its own proof. It verifies in a browser page, offline if need be, on a command line, or in your own implementation of the public specification — and it will keep verifying if this service is gone. The anchor is read from a public chain, not from us. Everything below exists because a server can answer one question a file cannot carry an answer to: whether a key has since been revoked. That can only make a verdict stronger.
If any step of your pipeline needs us to reach a verdict at all, that is a design error on our side. How to verify without us.
Start here
- Issue an API key for your organization's sandbox environment in the console. Keys belong to exactly one of three fixed environments, so a test key cannot reach production data.
- Call GET /api/v1/me and check that the key names the environment you think it does.
- Fetch a conformance vector from the sandbox and verify it. Its expected verdict comes from the public specification, so you can check our answer against something that is not ours.
- Read how a verdict is written before you branch on one.
Endpoints your key answers for
Everything below is authenticated with your API key. Two families of endpoint served here take no API key and are therefore not in this reference. The transparency log under /api/v1/log takes no credential at all, because the party being audited must not decide who may audit it: its signed tree heads, proofs and leaves, and at /api/v1/log/trust its entry for a trust document — the log's key and the digests of the app signing certificates it admits keys from. The device-facing API the capture apps use takes the apps' own tokens.
- GET /api/v1/me What the presented key is
- POST /api/v1/verify Verify a sealed file
- GET /api/v1/verify/watermark/{job_id} Poll an asynchronous verification
- GET /api/v1/sandbox/vectors List the conformance vectors this sandbox serves
- GET /api/v1/sandbox/vectors/{name} Fetch one vector and the verdict the specification expects
We keep no index of your media
No endpoint here looks a file up, and none resolves a core hash to anything. That is a refusal, not a gap: an index keyed on the media would be a correlation surface between somebody's pixels and their origin, and the platform will not build one — not for you, not for us, not for anybody who asks later. A verdict is computed and handed back; past the 24-hour idempotency window there is nothing left to look it up in.
The one lookup that exists is by capture id, on a public page, and it is a different thing in kind: the id is already in the file the asker is holding — in its proof, and in a photo's watermark — so answering it discloses nothing they could not read themselves. It answers with that capture's proof and nothing about the organization behind it — and only as far as that organization chose to publish.