Add verification to signup and account recovery

Connect a verification result to one specific customer action. For signup, the result can confirm control of the submitted address; for recovery, it can satisfy one step in your account's recovery policy.

Bind the intended action, destination and current session on your server before requesting a code. The browser can submit an address, but it should not decide which account or operation a later successful check authorizes.

Use the TypeScript or Python quickstart for the SDK's create-and-check calls. Store the returned verification ID with your attempt record so support can follow the same attempt.

Show the destination in a recognizable, appropriately masked form. Offer a way to correct a typo. Explain whether a resend is available and retain the original business action while the customer enters the code.

Validate the submitted code on your server. The SDK check takes the destination and code; your application must ensure that this destination is the one bound to the current session.

Advance the protected action only after a successful check. Mark the application's verification step as consumed so repeating a request cannot repeat a recovery action or create duplicate accounts.

A delivered code establishes delivery, not completion. Use the check result to advance the flow and events to observe the delivery lifecycle.

Keep application-level attempt limits, resend timing and abuse controls around the form. If the customer changes the address or phone number, start the intended verification flow for the corrected destination; do not transfer an earlier success to a different destination.

Test wrong codes, expired attempts, repeated submissions and a changed destination. Best practices and troubleshooting cover the operational checks.

Verify resources includes migration and channel guides.

Build the complete Next.js or Express verification form or FastAPI form, with a server-owned destination, retained check result and retry handling.