Skip to main content
One session is one person’s attempt at one verification. Create it server side. The secret key never leaves your server; the browser only ever sees the session_id.
Attach what ties the run to your records:

Anonymous checks

A verification configured as Anonymous collects no email and no phone. The person never sees an identity step, and three things follow that are easy to trip over:
  • Send neither email nor phone. Neither is rejected, but either one seeds the run and quietly turns it into a bound one, which is not what the verification is configured to do.
  • identity on the confirmation is always null. Do not build a flow that expects an address back, and do not ask the person for one to reconcile against.
  • There is no token-free lookup. POST /v3/confirmations matches on a credential, and an anonymous run binds none, so it answers 404 no_settled_pass every time. The vyt is the only way to read the result, so do not drop it.
While a run carries no identifier at all, an anonymous verification meters one successful pass per person, for life, ahead of any limit configured on the verification. Sending an external_id is enough to take the run out of that ceiling and restore the configured limit. If your second test run comes back denied, this is why.An option to control this is coming: check segmentation will let you group the collision gate, so a pass counts within a segment you define instead of once for life.
external_id is the only handle an anonymous check gives you. It is how you tie a pass back to your own record, and how duplicates get reported against your id. Minting server side is also your rate limit and your gate. Nobody can flood your account from a browser, and you decide which requests get a scan. Full parameters and errors: POST /v3/initialize.