A simpler way to begin.
Connect a verification to the account or session your customer is creating.
Verification API for OTP
Verification API.
A better way in.
Help customers sign in or confirm a phone number or email address with a one-time code. Send the code through the channel that fits, then check it before continuing.
fieldnotes. / Sign inYOUR APPLICATION / ACCOUNT ACCESS
Verify your number.
We’ll send a code to your chosen destination.
––––––
Pending verificationVerification lifecycle01
WhatsAppEligible in this configured example
↗02
SMSNext eligible channel in this plan
·03
ValidateCheck code, expiry, and attempts
·- Request
- vrf_example
- Pending action
- Account access
- Status
- Pending
fieldnotes. / Sign inYOUR APPLICATION / ACCOUNT ACCESS
Another way through.
Continue with the next available channel in the policy.
246810
SMS attempt selectedVerification lifecycle01
WhatsAppEligible in this configured example
✓02
SMSNext eligible channel in this plan
↗03
ValidateCheck code, expiry, and attempts
·- Request
- vrf_example
- Pending action
- Account access
- Status
- Awaiting code
fieldnotes. / Sign inYOUR APPLICATION / ACCOUNT ACCESS
You’re ready.
The code matched. Your application decides whether to authorise the action.
246810
Code verifiedVerification lifecycle01
WhatsAppEligible in this configured example
✓02
SMSNext eligible channel in this plan
✓03
ValidateCheck code, expiry, and attempts
↗- Request
- vrf_example
- Pending action
- Account access
- Status
- Verified
Example content and data. Explore the workflow below; nothing is sent or changed in a live account.
Companies that trust Bird across their communications.
Read Bird customer storiesBIRD VERIFYA confident next step.
DOCUMENTED OPERATING BEHAVIORA code match.
A code match.
A separate decision.
The maintained first-customer guide demonstrates create and check with recipient binding. It distinguishes delivery, an unsuccessful check and successful verification. Your application decides the authorized account action.
Read the integration example ↗Sources checked 18 September 2026. This illustration is not a live send or measured completion study. Current account and channel eligibility still apply.VERIFY / TRY IT YOURSELFKeep the happy path simple.
Keep the happy path simple.
Handle the rest deliberately.
Complete a successful code check in this example, then explore expiry, incorrect codes and another channel.
YOUR APPLICATION / PENDING ACTION
Example pending. Check 246810, or try 000000. No code is sent.Read the result and next step ↗
RECIPIENT / VERIFICATION
A code to continue.
246810
Illustrative sms code 246810. Original expiry: 12:10 UTC. Delivery does not replace a code check.
Example pending. Check 246810, or try 000000. No code is sent.
pending · 5 wrong checks left · 0 minutes elapsed · original expiry 12:10 UTC
Inspect the public result fields
Illustrative response observation; not a wire error envelope.
create: HTTP 200
{
"id": "vrf_example",
"status": "pending",
"reason": null,
"to": {
"phone_number": "+12025550142"
},
"channels": [
{
"channel": "sms"
}
],
"last_channel": "sms",
"expires_at": "2026-09-18T12:10:00.000Z",
"verified_at": null,
"created_at": "2026-09-18T12:00:00.000Z",
"updated_at": "2026-09-18T12:00:00.000Z"
}
Application record: pending action; no authorizationIllustrative choices: six digits, ten-minute lifetime, five wrong checks, 60-second resend cooldown. Actual configuration can differ. Resend keeps the original deadline and remaining check budget. Post-cooldown resends consume the recipient’s send cap; check-rate limits apply separately. Follow retry guidance after a 429.
Illustrative local flow · fixed fictional recipients and codes · no sends or account changes
WHAT IT MEANS FOR YOUR CUSTOMERHelp the right person
Help the right person
reach the next step.
Make verification a clear moment inside signup, recovery, or checkout. Give customers an understandable path forward, including when they need to try again.
A way back in.
Keep the pending recovery action and recipient together while your customer completes the check.
A deliberate next action.
Use the result in your application’s access or risk policy before completing the protected action.
FIND YOUR WAY IN
Build around the action you protect.
Design the first successful check.
Bind the same full recipient set to the pending action. Keep expiry, attempts and your application authorization separate.
Build your first verification ↗Design the recovery path too.
Resolve actual country/channel eligibility. Voice OTP requires rollout confirmation; a channel name does not establish access.
Plan the channel policy ↗READY WHEN YOU ARE
Take the first check all the way through.
BUILD WITH VERIFYSend. Check.
Send. Check.
Continue.
Two server-side excerpts: send in one request, then check in a later request after the customer enters the code. No code is sent from this page. Use your own phone number and keep the full recipient set bound to the application’s pending action. The SDK throws on API errors; HTTP 200 can still be success: false. Handle expiry, exhausted attempts, 422, 429 and uncertain responses; preserve known success across a later 404. A code match does not authorize the application action. Follow the integration guide for complete setup and error handling.
Create a verification and check the entered passcode with CLI or MCP. Inspect the success field before your application decides whether to continue.
Open the implementation guide →Code example
TypeScript// Send request: bind this recipient to the application's pending action.
const to = { phone_number: "+15551234567" };
const verification = await bird.verify.verifications.create({ to });
console.log(verification.status, verification.expires_at);
// Later check request: restore the same recipient and read the submitted code.
const result = await bird.verify.verifications.check({ to, code });
if (result.success) {
console.log("Code matched; the application must still authorize the action.");
} else {
console.log(result.reason, result.attempts_remaining);
}
THE COMPLETE BIRD PLATFORM
Verification is the beginning.
Once a customer completes verification, use Email for onboarding and SMS or WhatsApp for the moments that follow. Start with one product and build on the same platform.
LOOKUPThe number,
in context.
in context.
- Line type
- Mobile
- Ownership
- Not established
01
Lookup ↗
Inspect the address or number as useful evidence.
VERIFYA verified
beginning.
beginning.
- Request
- vrf_example
- Code check
- Verified
02
Verify This step
Check control of the destination before your app authorizes signup.
f.
FieldnotesTo: Alex Lee ⌄
A little room to discover.
fieldnotes.A PERSONAL INTRODUCTIONA little room
to discover.
Hi Alex,
Good things start here.
Explore your next moment ↗
to discover.
Hi Alex,Good things start here.
Explore your next moment ↗
03
Email ↗
Send a welcome after the account is created.
LEARN / BUILD / OPERATEGo further with
FIELD GUIDE
Go further with
Verify.
FIELD GUIDEBuild around the action you protect.
A practical path through setup, implementation, and the choices that matter.
Read the field guide →Explore all resources
Quickstarts, implementation guides, comparisons and migration.
Verify your first customer
Create and check a verification.
Orchestrazione dei canali
Understand policy, channel order, and moving to the next channel.
Troubleshoot a verification
Incorrect, expired, and exhausted attempts.
Plan verification costs
Understand the attempts and channels you pay for.
Verify securely
Bind the action, protect credentials, and handle retries.
Launch readiness
Prepare the recipient, sender, channel and recovery checks.
Email OTP
Verify access to a mailbox; address quality is separate.
SMS OTP
Check phone eligibility, code entry and attempts.
WhatsApp OTP
Explore eligible authentication and configured fallback.
Voice OTP rollout
Confirm access before a spoken-code evaluation.
Work through recipient binding, uncertain results and application authorization with a reusable implementation record.
VERIFY / PRICINGA completed check.
A completed check.
A considered cost.
No separate Verify or check fee is advertised. Delivering channels own usage charges; include extra resends and fallback attempts in the actual account and destination rates.
See Verify pricing ↗YOUR VERIFY SETUPChannel + attempts
Plan the delivery path and retry policy.
- Markets
- Confirm route availability and destination pricing.
- Attempts
- Include the billable attempts in your recovery policy.
- Application outcome
- Keep successful checks and actual completed signups separate. Missing evidence is not zero.
A FEW USEFUL ANSWERS
Verify, answered.
Which channels can I use?
Verify supports email, SMS, WhatsApp and Telegram under the recipient and country channel plan. Confirm current channel eligibility. Voice verification still requires separate rollout confirmation before including it in your implementation.
Do I have to create and store the code?
Bird handles code generation and checking. Your server requests verification and validates the code before it changes account or application state.
Does a delivered code mean the action is authorized?
No. Your application must check the verification result and bind it to the intended recipient and pending action.
What should happen after expiry or an exhausted attempt limit?
Treat the verification as unusable and follow your application policy for restarting. Handle the returned reason; do not accept an old code because delivery succeeded.
How do I get started or speak to sales?
Start with a Bird account and follow the setup path on this page. Our sales team can help with migration, volume, or a wider product mix. Start now or talk to sales.