Skip to main content
For a workflow whose mode is hosted. You create a verification with the person’s mobile number and send them in; they sign in with that number, work through the steps your workflow configures, and we send them back to your return_url. You never handle their documents. If the documents already reached you through your own onboarding, that is a staged workflow: see Staged. The mode belongs to the workflow, not to the verification, and creating one on a hosted workflow without a mobile is refused with 400.

​
Two ways in

A journey has two entrances. Which one you use depends on how the user arrives, not on what the workflow asks for: the steps, the record, and the redirect back to your return_url are the same either way. journey_url comes back on every read of the record. It is one fixed address per workflow, so you can template it into a WhatsApp message, print it on a QR code, or paste it into an email, and it keeps working for as long as the verification does.
The record, abridged
The user signs in there with the mobile number you passed to POST /verifications, which is also what makes the address safe to send over any channel. Only a number you have created a verification for can sign in, and each one reaches only their own journey, so the link is not worth guarding and is worth nothing to anyone else. A user can come back to it as often as they like, from whichever device they happen to be holding. For a user who reaches the journey from inside your own app and has already signed in to you, open it with a handoff instead: see Handoff.

​
Return URL and redirect

return_url is optional. Where you give one, the journey sends the user there when they submit, with two query parameters appended:
Your own query parameters on the return_url are preserved. A journey a gate check stops is not sent there. Only a redirect your system answers the check with sends the person anywhere, and only to a URL registered for the workflow.
These parameters render a landing screen. They are not signed and not proof of the outcome. Always confirm the real result by polling the API with the verification id.
A return_url must match one of the URLs registered for the workflow you are creating on, and matching is strict: the scheme and host must match exactly, the path must sit at or under an allowlisted path on a segment boundary, and only https is accepted. Plain http is allowed only for localhost during integration. The allowlist belongs to the workflow rather than to your account, so each of your journeys returns users to its own URLs and a uat workflow can send them somewhere else entirely. A workflow with no URLs registered takes no return_url at all.