What is a WhatsApp OTP API and how does it work?
A WhatsApp OTP API is a server-to-server call that asks Meta to deliver a one-time passcode to a user’s WhatsApp number, using a special message format called an authentication template. Your server creates the code, Meta delivers it, and your server checks what the user types back.
The moving parts are few. You need a WhatsApp Business Account (WABA) under a Meta business portfolio, a phone number registered on the WhatsApp Business Platform, an approved authentication template, and an access token your backend uses to call the Cloud API messages endpoint. When a user taps “Send code”, your backend generates a random number, stores a hashed copy with an expiry time, and sends the plain code as the template parameter. WhatsApp shows it in a chat from your business name with a button underneath.
Verification never happens at Meta’s end. The user either types the code, taps a copy button and pastes it, or, on Android, lets WhatsApp hand it straight to your app. Your server compares it with the stored hash, checks the expiry and the attempt count, and only then marks the number as verified or opens a session.
That split matters for security and for switching. Because generation and checking stay on your side, the WhatsApp OTP API is just one delivery pipe. SMS, email or a voice call can sit behind it as alternative pipes without changing how codes are checked.
- Your server: creates, hashes, stores and verifies the code
- Meta’s Cloud API: delivers the authentication template to WhatsApp
- WhatsApp app: shows the code with a copy or autofill button
- Your app or site: collects the code and posts it back for checking
Is WhatsApp OTP better than SMS OTP for Indian users?
For most consumer apps in India, WhatsApp OTP gives a smoother login, but it is not a full replacement for SMS. The right answer is usually WhatsApp first with SMS behind it.
WhatsApp wins on presentation and recovery. The code arrives in a chat that shows your verified business name, the copy button removes typing errors, and on Android a one-tap flow can fill the code without the user leaving your app. Users who switch SIMs but keep WhatsApp on the same number still get codes, and messages sent while the phone is offline arrive once data returns.
SMS still wins on reach. It works on phones with no data connection, on feature phones and for people who never installed WhatsApp. It is also what many banks and payment flows expect by habit. If your audience includes older users in areas with patchy data, removing SMS completely will lock some of them out.
Choose WhatsApp-first when
your users are smartphone owners, most signups come from Android, codes are requested often (login, not just signup), and you already use WhatsApp for order or booking updates.
Stay SMS-first when
your users skew towards feature phones or low data, the flow is tied to a regulated payment step where your provider requires SMS, or volumes are too small to justify another integration.
Offer a choice when
you serve both groups. A small “Get code on SMS instead” link after 30 seconds keeps everyone moving without doubling your costs.
WhatsApp OTP API authentication template rules you must follow
Every code sent through a WhatsApp OTP API must use a template in Meta’s authentication category, and that category has fixed wording. You cannot write your own sentence around the code the way you can with utility or marketing templates.
According to Meta’s authentication template documentation, the body text is preset as “{{1}} is your verification code”, where {{1}} is the code you pass in. Two optional extras can be switched on: a security disclaimer (“For your security, do not share this code.”) and an expiry line that states the number of minutes. Meta’s docs set the expiry field between a minimum of 1 and a maximum of 90 minutes. We recommend switching both extras on; they cost nothing and they reduce the chance of a user reading the code aloud to a scammer.
The button is the part you choose: copy code, one-tap autofill or zero-tap. The template is submitted with the language you need, so a Hindi and an English version are two separate template entries under the same name.
Keep the template for codes only. Do not try to slip a promotion into the authentication category; the fixed format leaves no room for it anyway, and misusing categories is a quick way to get templates rejected or your quality rating lowered. If you want to send a welcome message after signup, that belongs in a separate utility or marketing template.
- Fixed body text with the code as the only variable
- Optional “do not share” security line (switch it on)
- Optional expiry line, 1–90 minutes, matching your server’s expiry
- One OTP button: copy code, one-tap or zero-tap
- One template per language you support
Start with copy code because it works on every phone; add one-tap for your Android app once the basics run; consider zero-tap only when you have a strong reason and have read Meta’s terms for it.
Copy code shows a button that copies the code to the clipboard. The user switches back to your app or browser and pastes it. It is the only option for websites and the safe default for iPhone users. Meta’s documentation also notes that on iOS 26 and later, keyboard suggestions can offer the code from the WhatsApp notification, which removes most of the switching for iPhone users without extra work on your side.
One-tap autofill is an Android feature. The template carries your app’s package name and signing-certificate hash, and when the user taps the button WhatsApp opens your app and passes the code in. Your Android developer adds the receiving code in the app. If the app is not installed, or the hash does not match a debug or release build, the button falls back to copy code, so test with the exact signing key used for the Play Store release.
Zero-tap is also Android-only. WhatsApp broadcasts the code to your app in the background, so the user never taps anything. It is the fastest experience, but it hides the code from the user’s view, so it suits flows where you already trust the device context. Our table below compares all three.
How much does a WhatsApp OTP cost compared with DLT SMS?
A WhatsApp OTP is billed by Meta per delivered authentication message, while an SMS OTP is billed by your SMS provider per message sent. Which is cheaper depends on your current SMS contract and your monthly volume, so compare real rate cards rather than rules of thumb.
Meta’s pricing documentation states that from 1 July 2025 it charges per message, and only when a template message is delivered. Authentication is one of the four categories alongside marketing, utility and service. Meta also offers volume tiers: send more utility and authentication messages in a month and the per-message rate for that market drops, with tiers counted across all WhatsApp Business Accounts in a portfolio.
Two details matter for Indian teams. First, Meta’s pricing page lists India among markets with a higher authentication-international rate, but its own explanation says that rate applies only to eligible businesses based in a different country from the user; an India-based business sending codes to +91 numbers pays the domestic authentication rate. Second, Meta introduced INR billing for eligible India-based customers from January 2026, which makes reconciling your Meta invoice with GST accounts easier.
Remember the hidden costs on both sides: SMS needs DLT registration and fees charged by your aggregator, while WhatsApp needs a verified business portfolio and someone to watch template status. Our WhatsApp Business API cost page walks through Meta’s rate card in more detail.
- Pull last quarter’s SMS invoices and count OTP messages per month
- Estimate what share of those users have WhatsApp (most apps can check delivery on a pilot)
- Apply Meta’s current India authentication rate and your likely volume tier
- Add fallback SMS for the users WhatsApp cannot reach
- Compare the total, not the headline per-message price
Do you still need DLT registration if OTPs move to WhatsApp?
Yes, as long as SMS stays in your flow as a fallback, which it should. DLT rules apply to SMS, not to WhatsApp messages, but a fallback route is still commercial SMS.
Under TRAI’s Telecom Commercial Communications Customer Preference Regulations, 2018 (TCCCPR), commercial SMS in India can only be sent using registered headers assigned to the principal entity, and the content template has to be registered with the access provider, which scrubs outgoing messages against it. TRAI defines a header as an alphanumeric string of up to eleven characters. In short: your sender ID and your OTP text both need to be on DLT, as most Indian businesses already have them.
When we add a WhatsApp OTP API to an existing product, we reuse your current DLT header and OTP template for the fallback rather than registering new ones. The code value, expiry and wording on SMS should match what WhatsApp shows, so a user who receives both never sees two different codes.
One practical tip: if your registered SMS template says “valid for 10 minutes”, set the same expiry in the WhatsApp authentication template and in your server. Mismatched expiry messages are a common cause of support tickets after a switch.
How should SMS fallback work in a WhatsApp OTP API flow?
Send on WhatsApp first, wait a short, fixed time for a delivery signal, and send the same code by SMS if the signal does not arrive or Meta returns an error. Let the user trigger SMS manually as well.
WhatsApp tells your server what happened through webhook status updates: sent, delivered, read or failed. A failed status with an error such as “number not on WhatsApp” means you should switch to SMS immediately. No status at all after 20–30 seconds usually means the phone is offline or the number is not reachable; that is the moment to fall back, not after the code has nearly expired.
Use one code for both channels. Generating a fresh code for SMS invalidates the WhatsApp one and confuses users who then receive both. Record which channel delivered and which one the user actually used; after a month you will know your real WhatsApp reach instead of guessing.
- Step 1: user requests a code; server stores a hashed code with expiry
- Step 2: send the authentication template through the WhatsApp OTP API
- Step 3: watch for a delivered webhook for up to 20–30 seconds
- Step 4: on failure or silence, send the same code by DLT SMS
- Step 5: after 30–45 seconds show “Send by SMS instead” and “Call me” links
- Step 6: log channel, delivery time and success for reporting
How a WhatsApp OTP API integration is built, step by step
The integration is mostly backend work: one endpoint to request a code, one to verify it, and a webhook listener for delivery status. The app or website only needs an input screen and two API calls.
We start by setting up the WABA, phone number and template in your Meta business portfolio, then create a system user token with only the permissions the OTP service needs. On the server we write a small OTP module. It generates a six-digit code from a cryptographically secure random source, stores a hash (never the plain code) with the phone number, expiry and attempt counter, and calls the Cloud API messages endpoint with the template name, language code and the code as both the body parameter and the button parameter.
The verify endpoint compares the submitted code with the stored hash in constant time, checks expiry, increments the attempt counter and deletes the record on success. Delivery webhooks land on a separate endpoint that validates Meta’s signature header before trusting anything in the payload.
On the client we build or adjust the OTP screen: a single numeric field with autocomplete hints for one-time codes, a resend timer, a channel switch link and clear error messages. For Android one-tap we add the receiving activity and test with the Play Store signing key. For a React Native or Flutter app this sits in a small native module.
Rate limiting and fraud protection for a WhatsApp OTP API
Every OTP endpoint is a target, because each request costs you money and bots can request codes in bulk. Put limits in place before launch, not after the first unusual bill.
The common abuse pattern is simple: a script hits your “send code” endpoint with thousands of numbers, some of them premium or foreign ranges, and you pay for every delivery. WhatsApp reduces some of the premium-number risk that SMS carries, but you still pay per delivered message and your messaging limit can be eaten up by junk requests. The defence is layered and cheap to build.
We also watch the verify side. Without an attempt cap, a six-digit code can be guessed by brute force; with a cap of five attempts per code and a short expiry the odds become negligible. After repeated failures we lock the number for a period and flag the account for review.
- Per-number cap: for example three code requests per ten minutes
- Per-IP and per-device caps, stricter for new devices
- Country allow-list: only the calling codes you actually serve
- Invisible bot check or proof-of-work on the request form
- Attempt cap per code and a lock after repeated failures
- Alerting when hourly requests jump well above the normal pattern
- Never reveal whether a number is registered in error messages
WhatsApp OTP API throughput and messaging limits
Meta limits how fast and how widely a business can send, and OTP traffic counts towards those limits. Plan for them before a launch day spike.
Meta’s Cloud API documentation says a business phone number can send up to 80 messages per second by default, with higher throughput available on request. It also sets a pair rate limit: one message every six seconds to the same user, with short bursts allowed that then reduce what you can send next. That pair limit is why your resend button needs a timer; a user hammering “resend” will simply hit the limit.
Separately, messaging limits cap how many unique users you can reach outside a customer service window within a moving 24-hour period. Meta’s docs say a newly created business portfolio starts at 250, and the limit can rise through 2,000, 10,000 and 100,000 to unlimited. Meta applies that limit at portfolio level, shared by every number in it, so a marketing number and an OTP number compete for the same allowance.
For a new app expecting thousands of signups in week one, this is the single biggest launch risk. Start sending real OTPs a few weeks before launch, complete business verification early and keep marketing broadcasts away from the portfolio until your limit has grown.
Meta Cloud API directly or through a provider: choosing your WhatsApp OTP API route
Go direct to Meta’s Cloud API if you have a backend team that can maintain a small module; use a Business Solution Provider (BSP) if you want a dashboard, support desk and bundled SMS fallback and do not mind a platform fee.
Direct access means the only bill for messages comes from Meta, you control tokens and templates, and there is no extra hop between your server and WhatsApp. The trade-off is that you own error handling, webhooks, template monitoring and upgrades when Meta changes API versions.
A BSP wraps the same Cloud API with its own interface. Some add useful features such as automatic SMS failover or analytics. Check three things before you sign: that the WABA is created in your business portfolio (so you can leave), what they add per message or per month, and whether their OTP API passes the code through their logs.
We build either way. For many Indian startups a direct integration with a thin fallback to an SMS aggregator is the leanest setup, and that is what our WhatsApp Business API integration service covers in general.
Tech stack choices for a WhatsApp OTP API integration
Any backend that can make HTTPS calls can send WhatsApp OTPs, so we build in the stack you already run rather than adding a new service for the sake of it.
Typical combinations we work with: Node.js with Express or NestJS, Python with Django or FastAPI, PHP with Laravel, and serverless functions on AWS Lambda or Google Cloud. Codes and counters sit well in Redis because of its built-in expiry; if you do not run Redis, a database table with an expiry column and a clean-up job is fine for moderate volumes.
If your app uses Firebase Authentication, phone sign-in there uses SMS; a WhatsApp OTP can still be used by verifying on your own backend and then minting a custom token for Firebase. For web apps built on Next.js the OTP routes live in the same API layer as the rest of your auth.
Secrets
Keep the Meta access token and app secret in environment variables or a secrets manager, never in the mobile app. Rotate the token if a developer leaves.
Logging
Log request IDs, phone number hashes, channel and status. Do not log plain OTP values anywhere, including error trackers.
Version pinning
Pin the Graph API version in your calls and schedule an upgrade review when Meta announces deprecations.
How long does WhatsApp OTP API integration take?
Plan for two to four weeks from kickoff to production, and expect the calendar, not the code, to set the pace. Meta business verification and template review can take longer than the development itself if documents are not ready.
Week one usually covers WABA and number setup, template submission and the backend OTP module against a test number. Week two brings the client screens, webhooks and SMS fallback. Week three is testing: real Android and iPhone devices, low-network conditions, release signing keys for one-tap, and abuse tests on the request endpoint. A fourth week appears when we are also building login screens from scratch or when verification is delayed.
You can shorten the path by preparing your GST certificate or other business documents, a website that matches your business name, and access to your Meta business portfolio before we start. See the timeline table below for the phase-by-phase view.
Who owns the WhatsApp Business Account, number and OTP code?
You should own all of it: the Meta business portfolio, the WABA, the phone number, the templates, the access tokens and the source code of the OTP module. We work inside your accounts with permissions you grant and can revoke.
This matters more for OTPs than for most integrations, because login is the front door of your product. If a vendor controls the WABA and a dispute happens, your users cannot sign in. When the business portfolio and WABA are in your name, switching developers or providers is a token change, not a migration.
At handover you get the repository, a short runbook (how to rotate tokens, how to add a template language, what each alert means) and a walkthrough call in English or Hindi. The first two months of maintenance after launch are free; after that, support starts at ₹8,000/mo if you want us to stay on.
Worked example: a hypothetical test-prep app moving OTPs to WhatsApp
Say a test-prep app in Jaipur has an Android app, an iPhone app and a web dashboard, and students log in with phone OTPs several times a week. SMS delivery is fine most days but slow during exam-result peaks, and many students mistype codes on small screens. This scenario is hypothetical and meant to show the decisions, not a real client result.
We would keep their DLT SMS route untouched and add a WhatsApp OTP API in front of it. The Android app gets one-tap autofill with the Play Store signing key; iPhone and web users get the copy-code button. The server sends WhatsApp first, falls back to SMS after 25 seconds without a delivered status, and shows a “Send by SMS” link after 40 seconds.
Rate limits go in on day one: three requests per number per ten minutes, stricter caps for new devices, India-only calling codes, and an hourly alert. The template is submitted in English and Hindi with the security line and a 10-minute expiry that matches the SMS text.
After a month the app’s own logs, not our promises, show what share of logins completed on WhatsApp, how long delivery took on each channel and how much SMS spend moved. That data decides whether to keep WhatsApp-first for everyone or only for Android.
WhatsApp OTP API integration across India
We work remotely with product teams in every state, and login needs look similar everywhere: fast codes on budget Android phones, a backup for weak networks, and costs that stay predictable as signups grow.
Fintech and lending apps in Mumbai and SaaS products in Bengaluru tend to want strict fraud controls first. Ecommerce and D2C brands in Delhi, Surat and Jaipur care most about checkout logins that do not break during sales. Edtech and coaching platforms in Hyderabad, Pune and Kochi often need Hindi, Telugu, Marathi or Malayalam template versions. Clinics and diagnostic apps in Lucknow and Indore use OTPs for report access, where SMS fallback matters for older patients.
Wherever you are, the process is the same: a WhatsApp conversation with the developers, an itemised quote in about two working days, and development inside your own Meta and cloud accounts.
WhatsApp OTP API go-live checklist
Run through this list before you switch real users to WhatsApp codes. Each item has caused a failed launch somewhere, and each takes minutes to check.
- Business portfolio verified and display name approved
- Authentication template approved in every language you serve
- Template expiry, server expiry and SMS text all state the same minutes
- One-tap tested with the release signing key, not only debug builds
- Webhook endpoint validates Meta’s signature and handles retries
- SMS fallback fires on failure and on silence, with the same code
- Per-number, per-IP and per-device limits active and tested with a script
- Plain OTPs absent from logs, analytics and crash reports
- Alerts set for request spikes, template status changes and token expiry
- Messaging limit known, and marketing sends kept off the portfolio during launch
If you want these checks done as a fixed step in your release process, we can add them to your CI pipeline as part of ongoing maintenance.