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.