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. [Start now](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Fverify) [Talk to sales](/demo?product=verify) BIRD / VERIFY Illustrative experience Create a request · Choose the next channel · Check the code fieldnotes. / Sign in YOUR APPLICATION / ACCOUNT ACCESS Verify your number. We’ll send a code to your chosen destination. – – – – – – Pending verification Verification lifecycle 01 WhatsApp Eligible in this configured example ↗ 02 SMS Next eligible channel in this plan · 03 Validate Check code, expiry, and attempts · Request vrf_example Pending action Account access Status Pending fieldnotes. / Sign in YOUR APPLICATION / ACCOUNT ACCESS Another way through. Continue with the next available channel in the policy. 2 4 6 8 1 0 SMS attempt selected Verification lifecycle 01 WhatsApp Eligible in this configured example ✓ 02 SMS Next eligible channel in this plan ↗ 03 Validate Check code, expiry, and attempts · Request vrf_example Pending action Account access Status Awaiting code fieldnotes. / Sign in YOUR APPLICATION / ACCOUNT ACCESS You’re ready. The code matched. Your application decides whether to authorise the action. 2 4 6 8 1 0 Code verified Verification lifecycle 01 WhatsApp Eligible in this configured example ✓ 02 SMS Next eligible channel in this plan ✓ 03 Validate Check 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. - [Airwallex](/customers/airwallex) - Uber - [Zillow](/customers/zillow) - [Glovo](/customers/glovo) - PayPal - Adobe [Read Bird customer stories](/customers) BIRD VERIFY A confident next step. DOCUMENTED OPERATING BEHAVIOR ## 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 ↗](/docs/get-started/verify-your-first-customer) Sources checked 18 September 2026. This illustration is not a live send or measured completion study. Current account and channel eligibility still apply. ## 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 channel plan SMS · phone only Email · inbox only WhatsApp → SMS · configured example WhatsApp → email · full recipient set Received code · synthetic example 246810 Check example code ↗ Example pending. Check 246810, or try 000000. No code is sent. Read the result and next step ↗ Resend example Next configured channel Explore recovery + Advance example 60 seconds Expire example New example Response to inspect 429 · checks too fast 422 · invalid recipient 503 · result unknown 404 · no active verification 200 · unfamiliar reason Inspect response Inspect a response to explore recovery. RECIPIENT / VERIFICATION Inspect the public result fields Illustrative 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 Example pending. Check 246810, or try 000000. No code is sent. Code edited; no new check attempted. The application must inspect the next result before continuing. Example clock advanced. Resend does not move the original 12:10 UTC expiry. Checks are too fast. Pause, respect the server’s retry guidance and keep the pending action. Do not repeatedly resend. Definite refusal for invalid recipient input. Correct the complete recipient set before an authorized request; do not mark the action verified. The response is unavailable. Reconcile the original operation and your stored outcome before retrying; a lost response is not proof the check failed. Keep the earlier success. A later 404 does not undo it or require a new send. 404 can mean absent, expired, exhausted or already verified. Reconcile your application record; only start again if verification is still needed. Unfamiliar reason. Do not authorize or invent a retry rule; preserve the result and use supported troubleshooting. Application guard: this example is resolved. Review the pending action before selecting New example; no send is attempted. HTTP 200, success: false, expired. The original deadline passed. Review the still-pending action before a new verification. Enter the six digits from this illustrative message. No check was attempted; the wrong-check budget is unchanged. HTTP 200, success: true. The code matched this full recipient set. Your application authorizes the pending action separately. HTTP 200, success: false, incorrect_code. Correct the code; 5 wrong checks remain. HTTP 200, success: false, attempts_exhausted. Stop checking. A new verification needs your application’s restart policy. Resend cooldown: HTTP 200 returns the existing session; no new send. Keep the current code and expiry. This is separate from an HTTP 429 rate limit. New illustrative code 135790. Earlier 246810 still works before the original expiry while pending. The wrong-check budget is unchanged. Extra channel usage may apply. Advanced to sms. Code 135790 and delayed earlier 246810 can both match before the original deadline. The last channel need not be the converting channel. No further configured channel. A potentially delivered code remains valid while pending. Respect the resend cooldown; do not assume Voice fallback. WHAT IT MEANS FOR YOUR CUSTOMER ## 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. 01 / Welcome ### A simpler way to begin. Connect a verification to the account or session your customer is creating. 02 / Recover ### A way back in. Keep the pending recovery action and recipient together while your customer completes the check. 03 / Continue ### 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. Signup and account access ### 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 ↗](/docs/get-started/verify-your-first-customer) Channel and cost planning ### 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 ↗](/docs/get-started/verify-your-first-customer) ### The details behind your setup #### Signup & passwordless Bind the recipient to the pending session. Let the verification result determine whether the app continues. #### Checkout & recovery Use your application’s risk policy for the action. Never put a submitted verification code in logs. #### Channel & cost planning Read the resolved channel policy. Moving to another channel is an explicit supported operation; availability and charges depend on the route. READY WHEN YOU ARE ## Take the first check all the way through. [Start now](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Fverify) [Talk to sales](/demo?product=verify) 01 [Prepare your Verify workspace ↗ Check recipients, server credentials, senders and eligible channels.](/products/verify/getting-started) 02 [Create and check ↗ Follow the first-customer verification guide.](/docs/get-started/verify-your-first-customer) 03 [Plan recovery ↗ Exercise delayed earlier codes, incorrect/expired checks, rate limits and uncertain responses.](/docs/get-started/verify-your-first-customer) BUILD WITH VERIFY ## 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. [Create a verification ↗](/docs/cli/reference/verify-verifications-create) [Check a passcode ↗](/docs/cli/reference/verify-verifications-check) [Connect an MCP client ↗](/ai/mcp-client) [Open the implementation guide →](/docs/get-started/verify-your-first-customer) **Node.js**: `TypeScript` ```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); } ``` Examples: [TypeScript](/es-es/verification-api.ts.md) 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. [LOOKUP The number, in context. Line type Mobile Ownership Not established](/lookup) 01 ### [Lookup ↗](/lookup) Inspect the address or number as useful evidence. VERIFY A verified beginning. Request vrf_example Code check Verified 02 ### Verify This step Check control of the destination before your app authorizes signup. [A little room to discover. fieldnotes. A PERSONAL INTRODUCTION A little room to discover. Hi Alex, Good things start here. Explore your next moment ↗](/email) 03 ### [Email ↗](/email) Send a welcome after the account is created. BUILD YOUR BIRD SETUP A useful next connection. [Lookup ↗ Start with the destination Inspect available phone and email evidence.](/lookup) [SMS ↗ Reach a phone number Understand SMS senders and delivery context.](/products/sms) [WhatsApp ↗ A familiar channel Explore WhatsApp alongside supported verification options.](/whatsapp) [Email validation ↗ Catch an address mistake Help the customer correct an email before continuing.](/email-validation-api) Use Lookup when you need destination evidence, Verify when you need an ownership check, and Email or SMS for the welcome that follows. Each product does a distinct job in the same signup. [Plan your complete Bird setup ↗](/demo?product=verify) LEARN / BUILD / OPERATE ## Go further with Verify. [FIELD GUIDE Build around the action you protect. A practical path through setup, implementation, and the choices that matter. Read the field guide →](/docs/get-started/verify-your-first-customer) [Explore all resources Quickstarts, implementation guides, comparisons and migration.](/verify/resources) [01 Verify your first customer Create and check a verification. ↗](/docs/get-started/verify-your-first-customer) [02 Channel orchestration Understand policy, channel order, and moving to the next channel. ↗](/docs/guides/verify/sending-verifications) [03 Troubleshoot a verification Incorrect, expired, and exhausted attempts. ↗](/docs/guides/verify/events) [04 Plan verification costs Understand the attempts and channels you pay for. ↗](/docs/guides/verify/sending-verifications#cost-and-billing) [05 Verify securely Bind the action, protect credentials, and handle retries. ↗](/docs/guides/verify/best-practices) [06 Launch readiness Prepare the recipient, sender, channel and recovery checks. ↗](/products/verify/getting-started) [07 Email OTP Verify access to a mailbox; address quality is separate. ↗](/products/verify/email) [08 SMS OTP Check phone eligibility, code entry and attempts. ↗](/products/verify/sms) [09 WhatsApp OTP Explore eligible authentication and configured fallback. ↗](/products/verify/whatsapp) [10 Voice OTP rollout Confirm access before a spoken-code evaluation. ↗](/products/verify/voice) [Design an OTP verification flow ↗](/guides/design-an-otp-verification-flow) Work through recipient binding, uncertain results and application authorization with a reusable implementation record. VERIFY / PRICING ## 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. [Start now](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Fverify) [Talk to sales](/demo?product=verify) [See Verify pricing ↗](/products/verify/pricing) YOUR VERIFY SETUP Channel + 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. ## 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. YOUR NEXT CONNECTION ## A confident beginning. A simple verification. [Start now](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Fverify) [Talk to sales](/demo?product=verify) [Explore the whole Bird platform ↗](/products) ## Related resources - [Verify phone numbers at signup](/learn/series/verify-phone-numbers-at-signup) (video) - [What does OTP mean? One-time passwords explained](/explained/verify/what-does-otp-mean) (answer) - [Build your first integration](/learn/paths/integration) (course) [Get an implementation brief](/learn/workspace?topic=verify)