Redirect contract
If you passed a redirect_url in your /v1/verify call, the end user's browser is redirected there once the hosted verify page finishes — successfully or not — with two query parameters appended.
redirect_url is set per-request, not account-level — pass it with every /v1/verify call where you want a browser redirect. If omitted, the hosted page shows a static success/failure screen and doesn't redirect anywhere. This is separate from your account's webhook URL, which receives a server-to-server event regardless of whether a redirect_url was provided.Query parameters
| Field | Type | Required | Description |
|---|---|---|---|
| token | string | required | The session token — pass this to GET /v1/sessions/:token to confirm the real result server-side. |
| status | "verified" | "failed" | required | What the browser was told. Do not treat this as authoritative on its own. |
https://yourapp.com/verify/callback?token=7yV0N3z8_26yZpxtUKZRVRvy04KeHT5-&status=verifiedA query string is visible and editable by the person holding the browser. Never grant access, unlock a resource, or mark someone as verified purely because this redirect happened with
status=verified — always confirm with GET /v1/sessions/:token or the signed webhook first.Allowed redirect origins
redirect_url must be an https:// URL whose hostname is in your account's allowed redirect origins list, configured in Settings. A /v1/verify call with a hostname not on that list is rejected with a 400 before any verification session is created. This prevents your verification flow from being used to redirect users to an untrusted destination.
Recommended flow
- User lands on your redirect URL with
tokenandstatus. - Your backend calls
GET /v1/sessions/:tokenwith the token, server-to-server. - Trust that response's
status, not the query string. - Show the user the appropriate next screen in your own product.