How to set up an OTP flow on the WhatsApp Business API
Sending one-time passwords over WhatsApp lets customers verify logins, signups and transactions inside the chat they already use — no separate SMS gateway, no app switching, and delivery you can actually track. But WhatsApp OTPs run on the authentication message category, which has its own template rules, button behaviour and pricing. This tutorial walks you through building a production-ready OTP flow on the official WhatsApp Business API with InfiQ, from creating the authentication template to triggering codes from your app, testing end to end, and avoiding the mistakes that get OTP templates paused or messages marked as spam.
What you'll do
Create an approved WhatsApp authentication template with a copy-code or one-tap button, wire your backend to generate a code and call the send API (or trigger it no-code in InfiQ), test with your own number, then go live — authentication messages bill per delivered message.Before you start: what a WhatsApp OTP flow actually needs
An OTP flow on WhatsApp is not a normal marketing or utility message — it uses Meta's dedicated authentication message category, which unlocks purpose-built features like a copy-code button and a security-footer disclaimer, but also comes with stricter content rules (the code and a short verification purpose, nothing else). Before you build anything, make sure the groundwork is in place so approval and delivery go smoothly.
- An active WhatsApp Business API account connected through InfiQ, with your Meta Business Manager verified.
- A registered sender number in good standing — a fresh number should be warmed up before high-volume OTP traffic.
- Your backend able to generate and store a short-lived code (typically 4–8 digits, valid for a few minutes).
- A clear idea of where OTPs trigger: login, signup, password reset, checkout or a sensitive account change.
Step 1 — Create and submit the authentication template
OTPs must be sent from a pre-approved template in the authentication category — you cannot free-type an OTP message. In InfiQ's template manager, create a new template, set the category to Authentication, and choose your button type. WhatsApp fills the message body with a standardised security line, so you mainly configure the code delivery mechanism and optional add-ons. Submit it and Meta usually reviews authentication templates quickly, though allow time before a launch.
- Choose Copy code (customer taps to copy the OTP and pastes it into your app) or One-tap autofill where supported (the code is handed back to your app automatically).
- Add the code as a variable so each send injects the freshly generated OTP.
- Optionally enable the security disclaimer footer and a message-expiry line so users know the code is time-limited.
- Keep it strictly transactional — authentication templates cannot carry promotions, links or extra copy, or they will be rejected.
Step 2 — Generate the code and trigger the send
Your application owns the actual OTP: generate a random short-lived code, store a hashed or time-boxed copy against the user's session, then hand it to WhatsApp only as a template variable. In InfiQ you can trigger the send two ways — call the send API from your backend at the moment the user requests verification, or use a no-code flow/automation for simpler cases. The template name, the recipient number in international format, and the code variable are all you need in the payload.
- Generate the code server-side and set an expiry (for example 5 minutes); never send a code your backend cannot later validate.
- Populate the template's code variable and, for copy-code buttons, the button parameter as well.
- Send via InfiQ's API from your auth service, or map the trigger to a no-code automation for low-volume use.
- Log the returned message ID so you can reconcile delivery and read receipts against each verification attempt.
Step 3 — Test the full round trip before going live
Test with your own WhatsApp number first, on a real device, so you see exactly what the customer sees. Request a code from your app, confirm the message arrives with the correct OTP, tap the copy-code (or one-tap) button, and complete verification back in your product. Then deliberately try the unhappy paths — an expired code, a wrong code, and a re-request — to make sure your backend validation and rate limiting behave. Watching InfiQ's delivery and read status here confirms the message is genuinely reaching handsets, not just accepted by the API.
- Confirm the code in the message matches the code your backend stored for that session.
- Verify the copy-code button pastes cleanly and one-tap (where enabled) returns the code to your app.
- Test expiry, an incorrect code, and resend cooldowns so users can't brute-force or spam requests.
- Check delivery and read status in InfiQ to catch numbers that silently fail.
Step 4 — Go live, monitor quality and control cost
Once the flow works end to end, enable it for real users and keep an eye on two things: your number's quality rating and OTP delivery success. Authentication messages are billed per delivered message under the authentication category, so cost scales directly with verification volume — InfiQ shows this as transparent ₹ pricing (ex-GST) so you can forecast spend against sign-up and login numbers. Because OTPs are user-initiated and expected, they usually enjoy strong delivery and read rates, but a spike in failures or blocks is an early warning worth investigating.
- Watch quality rating after launch; sudden drops often mean users are blocking or reporting messages.
- Track delivery failure rate by number range to spot carrier or reachability issues.
- Remember authentication bills per delivered message — model cost against expected daily verifications.
- Consider a fallback path (retry or an alternate channel) only for users who genuinely can't receive WhatsApp.
Common mistakes that break OTP flows
Most OTP problems trace back to a handful of avoidable errors. The template gets rejected for containing anything beyond the code and its purpose; the wrong category is chosen, so the message either fails or costs more than it should; or a brand-new number is pushed straight into thousands of OTP sends and gets throttled. On the backend, teams forget to expire or rate-limit codes, turning a security feature into a vulnerability. Getting the template category and validation logic right from the start saves you a painful round of rejections and re-tests.
- Adding marketing copy, links or branding to an authentication template — it will be rejected.
- Using a utility or marketing template for OTPs instead of the authentication category.
- Not warming up a fresh number before sending high OTP volume.
- Skipping code expiry or resend rate limits, leaving the flow open to abuse.