Verify overview

Bird Verify confirms that a user controls an email address or phone number: you ask Bird to send a one-time passcode, the user types it back into your app, and you ask Bird whether it matches. Two API calls, POST /v1/verify/verifications to send and POST /v1/verify/verifications/check to confirm, with no sender registration, no templates, and no code storage on your side. Codes are delivered over email, SMS, and WhatsApp under Authifly, Bird's verification brand, so you can verify users before you've set up any sender of your own.

You create a verification with a recipient: an email address, a phone number, or both. Bird generates a numeric passcode, stores only a hash of it, and delivers it over the recipient's channels. An email address gets the code by email; a phone number gets it by SMS or WhatsApp, in the order and availability your country configuration sets for the destination country. The user types the code into your app, and you submit it to the check endpoint, which answers success: true or false with a reason.

A verification walks a small lifecycle: it starts pending, and ends verified (a correct code arrived in time), failed (too many wrong attempts), or expired (the window elapsed). The Verifications page shows every verification and its state; each state and reason is covered in Sending verifications.

In the dashboard, Verify is one of the workspace's apps. Its pages, and where each one's guide lives:

The Verifications page is the live view: every verification the workspace created, filterable by status, each opening a detail with the recipient, the resolved channel plan, and timing (see Track verifications in the dashboard). Programmatically, the check response carries the verification's full current state, and that is the read to build on: Verify emits no webhook events today, and its list and read endpoints are not part of the public API yet.

Verify delivers codes over three channels. Which one a recipient gets depends on the recipient type and, for phone numbers, your country configuration.

For a phone recipient, SMS is tried first and WhatsApp acts as a fallback by default; you can change the order, or turn a channel off, per country. If a send fails on one channel, delivery advances to the next one in the plan rather than failing outright. What each message looks like, the exact senders your users see, and how to brand the email sender are covered in Senders & branding; dedicated SMS and WhatsApp senders of your own are on the roadmap.

Every workspace starts on Bird's platform defaults for the code itself (length, lifetime), the check attempt limit, and the resend cooldown. Each is adjustable in the dashboard under Configure, and code length also per request; the values and ranges live in Verification settings. On top of these sit abuse guardrails you don't configure: per-recipient send and check caps, listed in Abuse guardrails.