WhatsApp OTP Verification: A Practical Setup Guide

A pharmacy delivery app we looked at lost a steady trickle of new users at the sign-up screen. The cause was dull: SMS codes took a minute or two to arrive, sometimes never, and people gave up. Moving verification to WhatsApp fixed the delay for many of them.

It is not a magic switch, though. A WhatsApp OTP has its own rules and its own ways to go wrong. Here's how we'd set it up.

Why WhatsApp for OTPs at all

Most of your users already have WhatsApp open on their phone, and messages there usually arrive quickly and sit in a chat the user trusts. SMS can be delayed by filtering rules and operator congestion. That said, some users don't have WhatsApp, so a fallback is not optional.

The flow, step by step

1. 1User enters their mobile number on your app or site.
2. 2Your server generates a random code, typically six digits, using a secure random generator and not something guessable like the time.
3. 3Your server stores a hash of the code with an expiry time and the number it belongs to.
4. 4Your server sends the code to that number through the WhatsApp API.
5. 5User types the code in. Your server compares it, checks expiry, and marks the number verified.
6. 6The code is deleted after use or after it expires.

Notice that the code is generated and checked on your server. WhatsApp is only the delivery truck. Don't build any logic that relies on WhatsApp telling you the user 'verified'.

Templates and the official route

A first-time OTP goes to someone who hasn't messaged you recently, so it falls outside the free conversation window. On Meta's Cloud API, that means a pre-approved template. Meta has had a dedicated category for authentication-style templates with stricter content rules, so check its current documentation for what is allowed and how it's billed.

Keep the wording plain: the code, who it is from, and a warning not to share it. Anything that smells like promotion in an OTP template invites rejection. Our guide on why templates get rejected covers the usual causes.

Rules we apply to the code itself

• Expire codes in a few minutes. Five is common.
• Allow a handful of wrong attempts, then lock that code and force a new one.
• Limit how often one number or one IP can request a code. Otherwise someone can use your form to spam strangers and burn your budget.
• Never log the code in plain text.
• Make each new code invalidate the previous one.

The fallback and the resend button

Show a resend button, but disable it for thirty seconds or so. People impatiently tap it five times, and each tap is a message you pay for and a code that overwrites the last. After a failed resend or two, offer an alternative such as SMS or a voice call.

Also tell the user what to expect on screen: 'We've sent a code to your WhatsApp ending in 42.' A little clarity saves a lot of support messages.

Testing before you go live

Send to your own number and your team's numbers while building. Don't test by firing codes at real customer lists. We wrote up a safer routine in testing a WhatsApp integration without spamming customers.

What this looks like on our side

Privacy and wording

Treat the phone number as personal data. Store only what you need, keep it out of logs where possible, and tell users in your privacy notice that you verify through WhatsApp. If your users are in a regulated setting such as lending or healthcare, check with your own advisor on what consent and record keeping you must have. We are developers, not lawyers, and we would rather say so than guess.

Keep the message itself short. Something like: your code for the app is 123456, valid for five minutes, do not share it with anyone. Adding a brand name helps users trust it. Adding a discount offer does the opposite, and on the official route it can get the template rejected.

A gateway such as WA Getway gives you a REST API with keys, so your backend can send a message when a login is attempted, and the paced queue keeps bursts under control. We would not claim it has a special OTP product. It is a sending channel, and the OTP logic lives in your app, which is where it should be.

If you want a hand wiring a verification flow into an existing app, that's the sort of custom work we take on. For the basic request format, our first REST API message walkthrough is a good starting point.