A short recipe for delivering one-time passwords on WhatsApp.
Why WhatsApp OTP
SMS can be expensive or unreliable depending on route and country. WhatsApp often delivers faster and feels familiar to users who already live in the app.
Flow
- User requests OTP in your app.
- Your server generates a 6-digit code and expiry (and stores a hash).
- Send via the WhatsApp OTP API using
/send-message. - User submits the code; you verify server-side and invalidate the code.
Example payload
{
"recipients": ["2547xxxxxxx"],
"type": "text",
"text": "Your code is 482901. Expires in 5 minutes."
}
Security basics
- Never log full OTPs in plaintext analytics tools.
- Rate-limit requests per phone and per IP.
- Expire codes quickly (3–10 minutes).
- Prefer WhatsApp for UX; keep email/SMS as fallback if your compliance policy requires it.
- Separate login OTP content from marketing so users trust the channel.
Product tips
Show a clear "Message sent to WhatsApp ending …78" state in the UI. If delivery fails, surface a retry and an alternate channel. Monitor instance connectivity so OTP outages are operational incidents, not silent UX bugs.
UX copy that reduces support
Tell users which channel carried the code. If WhatsApp fails, offer SMS or email without shame. Show expiry countdown. Disable the resend button for 30–60 seconds to reduce abuse.
Abuse and cost control
OTP endpoints attract bots. Combine CAPTCHA or device attestation on sensitive surfaces, per-phone rate limits, and anomaly alerts when one IP requests hundreds of codes. Even flat-rate plans suffer when your WhatsApp number reputation drops from abuse.
Multi-product consistency
Use one sentence structure across signup, login, and password reset so users learn the pattern. Changing tone every time trains people to distrust codes.
Accessibility
Do not rely only on WhatsApp. Some users share phones or lack data. Provide an alternate channel and clear expiry so lockouts are recoverable without a call center.
Practical scenarios
Here are concrete situations teams solve with this topic.
Scenario A — early-stage product
You need to prove WhatsApp automation this week. Connect a QR-linked number, send a transactional message, and measure whether customers understand and act. Keep the copy short. Log every API response. Expand only after the first path is reliable.
Scenario B — growing SME
Volume is rising and manual WhatsApp replies are failing. Automate the top one or two events first (usually payment or OTP). Train support on what the system already sends. Add scheduling and webhooks after the basics are stable.
Scenario C — developer platform
You are embedding WhatsApp into your own SaaS. Wrap FlareSend behind your service layer so product code never hard-codes HTTP details. Use queues, idempotency keys, and environment-specific API keys. Document the contract for your teammates.
Quality bar before you go live
- Happy-path send works on a real phone.
- Failure path shows a clear customer message or retry.
- Disconnects are visible to an operator.
- Consent or transactional justification is written down.
- Someone owns monitoring for the next 30 days.
Common mistakes
- Treating WhatsApp like email blast infrastructure
- Mixing marketing copy into OTP or payment messages
- Ignoring quiet hours across African timezones
- Skipping idempotency on payment webhooks
- Leaving staging keys pointed at production numbers
Fix those five and most production incidents disappear before they start.
What to read next on FlareSend
Browse related solution pages from the footer Solutions menu, skim the FAQ for safety and pricing questions, and keep the API docs open while you implement. When you are ready, start the free trial and ship one real customer workflow end to end.
Field notes from production teams
Teams that succeed with WhatsApp automation treat it like payments infrastructure: monitored, idempotent, and owned by a named engineer. They write runbooks for disconnects, keep a staging number for tests, and review failed sends in the same standup as failed transactions. They also refuse to use the channel for unsolicited cold outreach, because reputation damage is expensive to reverse.
If you are mid-implementation, pick one customer journey, instrument it, and only then expand. Breadth without reliability creates noisy support queues. Depth with clear metrics creates a channel customers trust.
Finally, keep FlareSend docs and your internal README linked from the same place. On-call engineers should not hunt for curl examples during an incident.
Implementation checklist
- Confirm consent or transactional context before sending.
- Store API responses for support audits.
- Prefer background jobs so web requests stay fast.
- Respect quiet hours for your customers' timezones.
- Link every automation to a clear customer benefit.
Related FlareSend resources
Try FlareSend
Connect WhatsApp in minutes and send OTPs, notifications, or bulk messages from one API.
Start free 4-day trial View pricing