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 that applies: your company, or one group inside it). 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 secret key (sk_…) stays on your server. It mints sessions at initialize and confirms tokens. The browser needs no key at all: it opens the session your server minted with vycheck({ session }). Publishable keys (pk_…) are deprecated. Never ship a secret key to the client.
Each key comes in a test and a live flavor (sk_test_… / sk_live_…). Test keys run the simulator and create test people, isolated from live records. Build against them freely. Switch to the live key to verify real people.
Most often it’s an anonymous person whose device ID is gone: they cleared the browser, switched devices, or used a private window. They look new, but their face is still on record, so they collide with their own earlier verification. Bind repeat visitors to 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. A person with a bound identity is also recognized on new devices: their face is matched and they sign back in with their number or email to re-assert their claim. An anonymous person is recognized only by the device ID in their browser, so they re-verify more often. See Returning people.
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. Duplicates are reported against your id. See Account linking.
Usually not lock. Use your own idempotency on the submission so the same token is not accepted twice. That stops a resubmission without affecting the person’s ability to verify again later. For caps like once per week or once per event, set a verification limit in the dashboard.Reach for locking only when you mean one pass per person, ever. Locking applies to the person’s confirmation, not just the token in your hand: their future passes on this verification come back denied too, and there is no unlock. After locking, GET /v3/confirmations/{token} returns verified: false.