Skip to main content
When a user returns from the hosted flow, they carry a vyt token. GET /v3/confirmations/{token} exchanges that token for the authoritative result. This is the check that matters: run it on your backend with your secret key before you grant access. The vyc value the client sees is only a UI hint.
Secret key only. Never confirm from the browser, that would expose your secret key. Use the secret key from the same pair as the publishable key that started the flow: test with test, live with live.
This page is the guided walkthrough. To see every endpoint and try it out against the live API, use the API Reference. It is generated from the same spec, so it never drifts.

​
Path parameter

​
string
required
The vyt confirmation token the user returned with after verifying. Read it off the URL or the embedded flow’s result with vyget().

​
Response

​
boolean
Authoritative result. true only if the person passed the liveness and uniqueness checks and the confirmation isn’t locked. Gate access on this field.
​
string | null
The confirmation id for this person’s pass through the verification.
​
string | null
Verdict detail: pending, approved, flagged, or denied. flagged means the check passed but carries findings for you to review.
​
string[]
The rule findings behind the status, for example collision when the same face was seen under someone else, or identity_mismatch. Empty on a clean pass.
​
string | null
When the latest settled verdict landed, as an ISO timestamp.
​
object | null
The email or phone the flow verified, present only when the verification’s identity configuration has sharing enabled in the dashboard.
​
string | null
The external_id attached to the session at initialize, if any.
​
object
A reference to the verification this confirmation belongs to.
Response

​
Example

Confirm each token exactly once. If your framework can double-fire the confirming code (React StrictMode does this in development), add a guard so the same token isn’t confirmed twice.

​
Errors

Errors return the matching HTTP status and a JSON body with a detail code:
A declined or locked confirmation is not an error. It returns 200 with verified: false.

​
Lock a confirmation (optional)

For true one-shot flows, where each person should pass exactly once and never again, lock the confirmation once you’ve accepted it. After locking, GET /v3/confirmations/{token} returns verified: false for that confirmation.
​
boolean
true once the confirmation is locked. A locked confirmation can’t be confirmed again.
Response
Locking applies to the person’s confirmation on this verification, not just the token in your hand. Once locked, that person’s future passes come back denied too. Use it only when one pass per person, ever, is exactly what you want. For caps like once per week or once per event, configure a verification limit in the dashboard instead. And don’t lock while you’re testing, or you will deny your own test user on every retry.