Skip to main content
That the person passed two checks: they’re a live human (liveness — not a photo, video, mask, or generated face) and they’re unique (their face doesn’t match anyone who already verified in their uniqueness pool). A confirmation returns verified: true only when both pass.
No — treat it as a UI hint only. Anyone can edit a URL. Always send the vyt token to your backend and confirm it with your secret key. That result is authoritative.
The publishable key (pk_…) is safe in the browser and is what the SDK uses to start a verification. The secret key (sk_…) stays on your server and is required to confirm tokens, lock confirmations, and attach identities at initialize. Never ship a secret key to the client.
Each key comes in a test and a live flavor (pk_test_… / pk_live_…, sk_test_… / sk_live_…). Test keys run a sandbox flow that creates test users — build against them freely. Switch to live keys to verify real people.
Most often it’s a guest who cleared their browser identifier. They look like a new person, but their face is still in the uniqueness pool — so they collide with their own earlier verification. Verify repeat users as accounts (bind a phone or email) so their uniqueness is permanent and portable.
No. A recognized human passes through quickly. Account holders are recognized permanently — across devices, browsers, and products. Guests are recognized by a browser identifier and re-verify more often, because guest uniqueness is cleared on a rolling basis. See Returning users.
The hosted flow hands the session off to their phone via a QR code, runs the camera step there, and brings the desktop along automatically over a realtime channel — no copying codes or refreshing. See Humanness and uniqueness.
Pass external_id (and optionally phone/email) at initialize from your server. The external_id comes back on the confirmation. See Account linking.
Lock the confirmation once you’ve accepted it. The token becomes invalid for that verification, so re-checking it returns verified: false.
Register a webhook. You get a signed event at each step — including liveness_failed, liveness_cancelled, and face_collision, which are where funnel loss shows up.
That’s the Platform API — provision verifications per customer, white-label the flow, and let your users add verification to their own flows. It’s under construction; reach out if you’re building on it.