Get Started
Integrate / SDKs
User Verification
Business Verification
Transaction Monitoring
ChangelogPrepare your integration
Hosted sign-in keeps proof collection and required MFA in the authentication flow. Your application should preserve retryable user input, show a useful error, and offer a new sign-in attempt after an expired transaction. Never suppress a challenge or retry failed passwords in a loop. Keep your callback URL and allowed origins exact. Do not send API keys, refresh tokens, passwords or recovery codes as device metadata. A device signal is context for a policy decision, not proof of identity.Planned protections
The planned policy modes are Off, Log, Challenge and Block. A challenge may require a passkey, email code or selfie when supported and configured. Do not assume an email proof and an identity-verification result provide the same assurance.
Timed attack mode is planned to apply stronger protection temporarily and switch off after its configured duration. Check the actual application state before showing an active-mode banner. No configuration endpoint or request field is prescribed here before the release contract is available.
Handle limits and recovery
Respect a returnedRetry-After header and avoid simultaneous retries. Keep errors generic where necessary to avoid revealing whether an account exists. Treat a blocked attempt as blocked; unavailable device context must not become a fabricated successful check.
Test expired challenges, wrong proof, MFA enrollment, recovery-code reuse, rate limiting, sign-out and disabled sign-in methods. When advanced policies become available, test each enabled mode and automatic attack-mode expiry in your application’s sandbox before enabling them live.
Read events and webhooks for activity coverage and the JavaScript quickstart for the hosted flow.