Pick your identification touchpoints
Start with one action whose outcome you can measure:
Pass a stable pseudonymous User HID on signed-in pages. Regular checks have a same-user visit cooldown; use a force-check method when a protected action needs fresh evidence. See snippet methods.
Decide how to act on users and identifications
Read the current check’s Risk Score and flags together with account history and High-Risk Events. The analytics dashboard’s current identity category has a separate calculation. A VPN can put a legitimate customer in the Suspicious risk band; choose verification or review appropriate to the action. Acting on results gives example policies. Test legitimate shared devices, travel, account recovery and repeated requests before broad enforcement.Plan how you receive results
- Scored webhook: push delivery of
identification.scored, verified over raw bytes. - History: retrieve individual identifications by Identification ID or another supported identifier.
- Multi-account group webhook: separately enabled
hre.multi_account.changed, with members and revisions instead of a check’s Risk Score.
Plan what you store
Keep the Identification ID with the application action, the expected account and domain, the evidence used, and the final action outcome. For webhooks, deduplicate delivery byevent_id. For protected benefits, atomically record that the accepted identification has been consumed. Group events additionally need revision ordering within their publication and group scope.
Store only the evidence needed for your retention and review process. Record enough to explain or reverse a decision.
Map the install and the call
The browser SDKs wrap the same identification flow. Their Promise-based API differs from the CDN snippet’s callback API; follow the guide for the package you install.