Getting started

A key names an environment

Every tenant has three environments and they are fixed: dev, sandbox, production. An API key belongs to exactly one of them, and the environment's name is inside the token:

vcap_sandbox_a1b2c3d4_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
└─────────────────────┘ └──────────────── secret, shown once ──┘
  public prefix — the whole of it, environment included

You choose the environment by choosing the key. There is no second switch — no test: true flag, no separate host — because two ways of saying the same thing can disagree, and the failure mode of that disagreement is test traffic landing on real data. The part up to the last underscore is the key's public prefix: it is what appears in logs and in the console, and it is safe to paste into an issue.

Issue one

In the console, open your organization, then the environment, then Create API key. The full token is displayed once; afterwards only its SHA-256 digest is stored and nobody — us included — can show it to you again. Revoking is immediate and does not affect the other environments.

Check what you shipped

curl -H "Authorization: Bearer $VCAP_API_KEY" "$VCAP_API_BASE/api/v1/me"

{"organization":"…","environment":"sandbox","key":"vcap_sandbox_a1b2c3d4"}

Do this from the deployment itself rather than from your laptop. The question it answers is not "is this key valid" but "is the key this process holds the key I meant", and only the process can answer that.

Unknown, malformed, wrong-secret and revoked keys all answer the same 401 VCAP_UNAUTHENTICATED. That is deliberate: an answer that told them apart would let a prober learn which prefixes exist.

Verify something

Send the file, base64. If the proof lives beside the file as a .vcap sidecar rather than inside it, send that too. A proof in the file's own C2PA Content Credentials is read from the file; a manifest store kept beside it as a .c2pa goes in c2pa_store_b64. The verdict's proof_source says which of these the proof came from.

curl -X POST "$VCAP_API_BASE/api/v1/verify" \
  -H "Authorization: Bearer $VCAP_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"media_b64\":\"$(base64 -i photo.jpg)\"}"

The answer is a verdict, even when the file has no proof at all — that case is no_proof_found, not an error. Before you branch on one, read how a verdict is written; then get real files with known expectations from the sandbox.