Skip to main content
With your check configured on the dashboard, mint a session for it on your server and return the session_id to your frontend. There is no browser path to a session; your secret key, and the decision to spend a scan, stay server side.
A session carries at most one identifier, tying the run to whatever you already use for the account:

Groups

Uniqueness covers the whole verification: once someone passes, every later run through that check reads as the same person, and a repeat attempt reports as a duplicate. Sometimes that is too broad. If one check gates several distinct things, separate surveys or product drops for instance, send a group to scope uniqueness to each one. The same person can then pass once in spring-intake and once in fall-intake, but never twice in either. Sometimes one pool needs to see another. To keep everyone who already passed spring-intake out of a follow-up, mint the follow-up’s sessions with its own group plus include_groups: ["spring-intake"]. History in an included group counts against the run exactly as its own would: whether a hit denies the person or only flags the pass follows the verification’s settings, and the confirmation’s groups field names the pools the hit came from. The run still settles into its own group. An included pool is read, never written.

Anonymous checks

A verification configured as Anonymous sends people straight to the check, with no identifier step. It fits flows where nobody returns, and it carries trade offs:
  • After a person’s token expires, you have no identifier to look them up by.
  • Reusing the verification requires a group. Without one, any repeat attempt through it is blocked.
Anonymous does not mean client side. The session is still minted on your server, for two reasons: a browser alone cannot flood your account with scans, and you choose when a check runs at all, so a request your own signals flag as low quality never spends one. A scan is spent deliberately.
Even with no identifier on the run, an anonymous verification meters one successful pass per person, for life. If your second test run comes back denied, this is why. Send a group to reuse the verification, and the pass counts once per group instead.
For full parameters and errors: POST /v3/initialize.