Security & data handling

Every identify request goes through our gateway, not directly to any upstream model or provider — your client never sees or holds an upstream provider key.

An image you submit (file upload or a fetched image URL) is used to fulfill that request and, in aggregate, to power the accuracy flywheel that re-indexes the catalog nightly. We don't sell images, and we don't share them with anyone outside the systems that produce your identify result.

Corrections you send back via POST /v1/feedback are used the same way — to improve future match quality, not resold or repackaged as a dataset product.

An identical resubmission of the same image is served from a short-lived exact-image cache, which is why repeat scans of the same photo come back close to instantly.

Every request authenticates with a bearer API key (Authorization: Bearer cvk_live_…), issued from your dashboard and completely separate from any session cookie.

Keys are shown in full exactly once, at creation. After that we only ever display a public prefix and the last 4 characters — if you've lost the full key, the fix is to rotate, not to ask us to recover it.

On our side, keys are stored as a SHA-256 hash, never in plaintext. Each key carries 192 bits of randomness, which is why we don't run it through a slow password-hashing KDF — that trade-off is for low-entropy secrets like passwords, and we verify a high-entropy bearer key on every gateway call, so fast and deterministic is the correct choice here.

Rotate a key any time from the dashboard: generate the replacement, update your server-side config, then revoke the old key once traffic has moved over. We recommend rotating on a schedule for any key that touches production, and immediately if a key may have leaked (committed to a public repo, logged in plaintext, shared over an insecure channel).