Tutorial · 4 min read
Sending OTPs on WhatsApp: The Authentication Template
Of everything businesses send on WhatsApp, the one-time passcode is the most tightly specified. It has its own template category, its own restrictions on what the message may contain, and its own reason for existing: Meta would rather define the format than have every business invent one and slowly turn it into a marketing surface.
That constraint is the useful part. Most of the design decisions are already made for you.
Authentication is a category, not a label
WhatsApp templates carry a category, and the category is not cosmetic — it governs review and it governs pricing. Marketing, utility, authentication and service are treated as different things by Meta.
Authentication templates exist for verification codes and account access. They are reviewed against that purpose, and the review is unsympathetic to anything that drifts from it.
What the format gives you
WhatsApp provides purpose-built handling for one-time passcodes rather than expecting you to send free text. In practice that means the message body is largely standardised, the code sits in a variable, and the button options exist to let the user copy or hand the code back to your app without retyping it.
Two consequences worth planning for:
- You have very little copy to write. This is a feature. A code message that reads exactly like every other code message is a code message users trust.
- The behaviour is the product, not the wording. Whether the code arrives in three seconds and can be used in one tap matters far more than the sentence around it.
Opt-in still applies
An authentication template is an outbound message to a closed window, so the general rule holds: Meta requires businesses to obtain opt-in before sending template messages.
For OTPs this is usually straightforward, because the user is standing at your signup or login screen asking for the code. Capture consent to receive it on WhatsApp explicitly at that moment, tell them which number it will come from, and record it. What you should not do is treat a phone number collected for verification as consent for anything else later — that is the step that turns a clean authentication programme into a spam complaint.
A number given to receive a code is consent for the code. It is not a marketing list, and treating it as one is how businesses lose the channel.
Delivery, fallback and the failure you must design for
WhatsApp delivery depends on the user having WhatsApp, being reachable, and the message not being throttled by your own quality standing. None of those are guaranteed at the moment someone is trying to log in.
- Always have a second path. SMS or email as fallback, triggered on a timeout rather than on user complaint. A login that can only complete over one channel is a login that fails on the day that channel has a bad hour.
- Give the user a manual escape. A visible "send it another way" option, not buried behind a 60-second wait.
- Make the code short-lived and single-use. Expire it quickly and invalidate it once used. These are the two boring properties that do most of the work.
- Do not log the code where it can be read. Application logs, analytics events and support tools are all places passcodes end up by accident.
- Rate-limit requests per user. Both to protect the user and to protect your own quality rating from a resend loop.
That is deliberately the whole security list. Anything more specific belongs with your security team and your regulator, not in a blog post about a messaging channel.
Cost, briefly
Meta prices conversations by category, and authentication is a category. So the cost of an OTP programme scales with how many codes you send, and the easiest saving available to most businesses is not a cheaper rate — it is sending fewer codes.
Long-lived sessions, remembered devices and not re-verifying users for trivial actions all reduce volume more than any pricing negotiation will. The cost model in general is here.
Keeps working
Degrades
What this has to do with Instagram
Almost nothing, honestly, and that is worth saying plainly rather than manufacturing a connection.
There is no equivalent of an authentication template on Instagram. The Instagram Messaging API is for replying to people who engaged with you — comments within seven days, DMs within twenty-four hours — and it is not a transactional delivery channel. PostEngage runs on that API and answers Instagram comments and DMs; sending verification codes is not a thing it does or could do.
If what you actually need is conversational automation rather than transactional delivery, the reply automation post is the more useful read, and the channel comparison covers which one is worth your first week.
