Skip to main content
That the person passed two checks: they’re a live human (a face check, not a photo, video, mask, or generated face) and they’re unique (their face doesn’t match someone else who already verified in the scope you chose, your company or the whole network). 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 whose device ID is gone: they cleared the browser, switched devices, or used a private window. They look like a new person, but their face is still on record, so they collide with their own earlier verification. Verify repeat users as members (a verified phone or email) so they can be recognized and re-linked instead of blocked.
No. Within your verification’s skip window, someone who already passed completes almost instantly. Members are also recognized on new devices: their face is matched and they sign back in with their number or email to re-assert their claim. Guests are recognized only by the device ID in their browser, so they re-verify more often. See Returning users.
The flow runs in place with their webcam. If they’d rather use their phone, one click shows a QR code that moves the same session to their phone’s browser, and the desktop follows along in realtime and returns to your site automatically when they finish. 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.