Skip to main content

​
Statuses

A verification moves through a small, durable set of states. There is no expiry: a user can return to an unfinished verification at any time.

​
Creating a verification

POST /verifications is idempotent per phone. The same phone number for your organization always resolves to the same user_id, so a retry replays the existing verification instead of creating a duplicate. You can safely call it again with the same number. The return_url you send must be on the allowlist we registered for you, or the call is rejected with 400. See Return URL and redirect below.

​
Identifiers

​
Timestamps

Timestamps are in IST. A verification carries created_at, and opened_at / submitted_at / cancelled_at, each null until the matching transition happens.

​
Return URL and redirect

When the user finishes, we redirect them to your return_url with two query parameters appended:
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 user_id.
Allowlist 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).

​
Ending or restarting

Reset is how you revive a cancelled or completed verification rather than stranding it.