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.
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 agroup 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.
POST /v3/initialize.