Free WhatsApp API for n8n and OTP: What Is Actually Free and What Is Not

Three separate things get called free in this search, and only two of them are. API access is free. A test number with a five-recipient ceiling is free. Verification codes are not - authentication templates bill per message from the first one you send.

Last verified: September 2026 against n8n's node documentation and Meta's WhatsApp Cloud API documentation. Rates and node operations change - check the linked sources before anything production-critical.

That last block is the one that surprises people. An OTP is by definition sent to someone who has not messaged you - they are on your signup form, not in a WhatsApp conversation. So there is no open window, the message must be a template, and the template is in the authentication category, which is always billable. There is no volume of free OTPs to start with.

The good news is that everything else really is free, including the entire build and test cycle. This guide covers the n8n setup exactly as the node works today, the authentication template rules Meta actually enforces, what you will pay, and the two limits that break OTP flows specifically. If you are still deciding between the sanctioned API and a GitHub library, read free WhatsApp API: official vs unofficial first - unofficial libraries cannot send authentication templates at all.

n8n ships a built-in WhatsApp Business Cloud node. It is a thin, honest wrapper over Meta's Cloud API - which is good news, because it means the platform rules in this guide apply unchanged. It is not a separate WhatsApp product with its own allowances.

The node exposes two resources and six operations:

Send vs Send Template is the decision that matters

Nearly every "my n8n WhatsApp workflow does not work" report comes down to using Send where Send Template was required. Send emits a free-form message, which WhatsApp permits only within 24 hours of the recipient's last message. Fire it at a signup form submission and Meta rejects it with 131047, the re-engagement error. For OTP, Send Template is the only correct operation.

Send and Wait for Response is more interesting than it sounds

This operation pauses the workflow until the recipient answers, offering approval buttons, free text, or a custom form. For an OTP flow it is a tempting way to collect the code back from the user - but be careful: a paused n8n execution holds workflow state open, and OTP codes should expire in minutes. Prefer a short wait with an explicit timeout branch over an open-ended pause. n8n also exposes the node as a human-in-the-loop tool for AI agent steps, which is a genuinely good fit for approval flows and a poor one for verification.

n8n uses two different credential types for WhatsApp, and picking the wrong one is the most common setup failure. The credentials documentation is explicit about the split.

The token that expires in 24 hours

The access token offered on the API Setup screen is a temporary one and it expires after 24 hours. Build a workflow with it and everything works beautifully through your first afternoon, then fails overnight with:

{
  "error": {
    "message": "Error validating access token: Session has expired",
    "type": "OAuthException",
    "code": 190
  }
}

The fix is a System User token, not a longer temporary one. In Business Settings, create a system user, give it a role on your WhatsApp Business Account, and generate a token with whatsapp_business_messaging and whatsapp_business_management. Paste that into the n8n credential. Error 190 has the full subcode list, and the pattern is covered in our WhatsApp API error codes reference.

Business Account ID is not the Phone Number ID

Two IDs sit next to each other on the API Setup screen and they are not interchangeable. The credential wants the WhatsApp Business Account ID (the WABA). The Phone Number ID goes into the node parameters as the sender. Swapping them produces a permission error rather than anything that names the real problem, which is why this costs people an hour. WhatsApp Business API setup walks the whole account structure if the portfolio, WABA and phone number hierarchy is still fuzzy.

Outbound is half the job. To verify a code you have to receive the user's reply, and that means the WhatsApp Trigger node, which subscribes to Meta's webhook events.

It can listen for ten event types: Account Review Update, Account Update, Business Capability Update, Message Template Quality Update, Message Template Status Update, Messages, Phone Number Name Update, Phone Number Quality Update, Security and Template Category Update.

For an OTP flow you want Messages to catch the reply and delivery statuses. Two others are quietly valuable in production: Message Template Status Update tells you the moment a template is approved or rejected, and Phone Number Quality Update warns you before quality-driven restrictions start biting.

The trap: one webhook per app

n8n's own documentation flags this and it deserves the emphasis. "WhatsApp only allows you to register a single webhook per app." The consequence: "every time you switch from using the testing URL to the production URL (and vice versa), WhatsApp overwrites the registered webhook URL" - so activating a workflow to test it silently steals events from your live one, and vice versa.

The documented workaround is to temporarily unpublish the production workflow while testing, then republish. If you need genuine parallel environments, the clean answer is a second Meta app with its own WABA and its own test number, not a second workflow in the same app.

If events never arrive at all

Verification and subscription are separate steps. A callback URL that verified successfully still receives nothing until you subscribe to webhook fields - messages being the essential one - in the App Dashboard under WhatsApp → Configuration, and until the app is subscribed to your WhatsApp Business Account. Meta will also disable a webhook that repeatedly errors or times out, with no runtime signal at all. Our webhook not firing debugging guide covers the full check order.

When you create a Meta app with WhatsApp added, Meta automatically provisions a test WhatsApp Business account and a test business phone number. Per Meta's Cloud API overview, test accounts and test numbers do not require a payment method on file in order to send template messages.

That is a real, usable free tier for development. It has one hard boundary: the test number can send free messages only to a small set of recipient phone numbers you add and verify - the current ceiling is five, listed on the WhatsApp limits page. Each recipient has to confirm with a code before you can message them.

The step where free ends

Going live means registering your own business phone number, which requires a payment method, and starts you at the lowest messaging tier - 250 unique customers per rolling 24 hours until Meta raises it. Note that the number must not already be active on the WhatsApp consumer or Business app; if it is, registration fails in ways covered by WhatsApp number registration failed. The registration endpoint itself is limited to 10 attempts per number in a 72-hour moving window, so trial-and-error onboarding runs out of attempts quickly.

You cannot write your own OTP message. Meta's authentication template specification uses fixed, non-customisable preset text, and rejects attempts to override it.

The body is the preset string <VERIFICATION_CODE> is your verification code. - you supply the code, not the sentence. Meta's API documentation states plainly that The text property is not supported and The autofill_text property is not supported. Teams that budget a week for OTP copywriting are budgeting for something that does not exist, which is genuinely good news: no copy to write means no copy to get rejected.

Two optional elements are available:

• Security disclaimer. Appends "For your security, do not share this code." to the body.
• Code expiration footer. Renders "This code expires in <NUM_MINUTES> minutes." and accepts a value from 1 to 90 minutes.

The three button types

The practical advice is to ship COPY_CODE first. One-tap and zero-tap are meaningfully better experiences and they are Android-only integrations with real app-side work; adding them later changes the template, not your backend.

Length limits that catch OTP flows

The copy code button carries a code of at most 20 characters. That is generous for a six-digit OTP and tight if you were planning to pass a signed token. Keep the code short and numeric. If a template send starts failing for everyone at once, it is a 132xxx problem rather than a recipient problem - 132000 for parameter count, 132001 for a name or language mismatch. Run drafts through the free WhatsApp template checker before submitting, and read WhatsApp template rejected if review sends one back.

Meta moved from per-conversation to per-message billing on 1 July 2025. Every authentication template message you deliver is billed - there is no free allowance, no first-thousand-free, and no way to route an OTP through a free category.

What varies is the rate, along three axes:

• Recipient country. The single biggest factor. Authentication rates differ substantially between markets, and Meta publishes per-country rate cards rather than one number.
• Authentication vs authentication-international. Meta's pricing documentation notes that specific countries carry a separate authentication-international rate, which our limits reference records as a distinct rate introduced alongside the 2026 adjustments. If you verify users across borders, model it separately - it is the line item that turns a modest OTP budget into a surprising one.
• Monthly volume. Utility and authentication rates step down at higher monthly volume, aggregated across every account in your business portfolio and reset monthly. Marketing is not tiered.

Model it before you build

OTP volume is unusually easy to forecast, because it is a direct function of signups and logins, and unusually easy to underestimate, because of resends. A realistic model needs signups, login-verification frequency, a resend rate (10-20% is not unusual when delivery is slow), and your actual country mix. Put those into the WhatsApp API cost calculator rather than multiplying one headline rate by one volume number.

Two cost controls are worth building in from day one. Rate-limit resends per user - a 60-second cooldown removes most duplicate spend and is good security practice anyway. And fall back rather than retry: if a WhatsApp OTP fails as undeliverable with 131026, that recipient is not on WhatsApp or has blocked you, and every retry is money spent on a message that will never arrive. Mark it terminal and use another channel.

The whole thing is four nodes plus a verification path. What makes it work is that the code lives in your store, not in the workflow.

1. Webhook trigger - your signup form posts the phone number to an n8n endpoint.
2. Code node - generate a six-digit code, hash it, store it with the phone number and a short expiry.
3. WhatsApp Business Cloud → Send Template - your approved authentication template, with the code as the body parameter and the same value on the copy-code button.
4. Respond - tell your app the code was sent.

The template send maps to this Cloud API payload, which is worth recognising because n8n's node produces it and error messages refer to it:

{
  "messaging_product": "whatsapp",
  "to": "447700900123",
  "type": "template",
  "template": {
    "name": "verification_code",
    "language": { "code": "en" },
    "components": [
      { "type": "body",
        "parameters": [{ "type": "text", "text": "482913" }] },
      { "type": "button", "sub_type": "url", "index": "0",
        "parameters": [{ "type": "text", "text": "482913" }] }
    ]
  }
}

Note the number format: full international, no leading +, no spaces, and no leading zero on the national portion. A UK mobile is 447700900123, never +44 07700 900123. Keeping the national zero is a leading cause of 131026 that has nothing to do with the recipient. Normalise numbers when they enter your system, not at send time.

Verification: two designs, one of them wrong

The safe design is the user types the code into your app, and your backend compares the hash. The WhatsApp message is a delivery channel and nothing more.

The tempting design is the user replies with the code on WhatsApp, caught by the Trigger node. It reads as elegant and it is weaker: replies can be delayed by minutes, the reply arrives from the same number you sent to (so it proves possession, but adds a wide timing window), and you now hold verification state in a paused workflow. Use it for convenience confirmations, not for anything guarding an account.

OTP is unforgiving because a failure is immediate and visible - the user is staring at an empty input box. Handle these five in n8n rather than letting the workflow error out.

The 132000 trap in OTP templates specifically

Authentication templates put the same code in two places - the body and the copy-code button - and those live in separate component arrays. Supplying two body parameters because you counted two placeholders produces 132000 even though the total is right. The payload above shows the correct shape.

Log the whole error, not the code

Meta's error_data.details field is written in plain English and is usually more specific than any lookup table, and fbtrace_id is the only thing Meta support can act on. In n8n, that means configuring the node to continue on error and capturing the full response body into your logging step - not just letting the execution fail with a status code. The full WhatsApp error-code directory maps each one to its fix.

Most rate limits are about scale. Two of WhatsApp's bite OTP flows at tiny volumes, and they are the ones nobody reads about until production. Both are on the WhatsApp limits page, and rate limiting in general is worth understanding before you design retries.

The pair rate limit: one message every six seconds

WhatsApp limits how fast a single business number can message a single user: roughly one message every six seconds, about ten per minute. This exists to stop businesses flooding individuals, and it is invisible at any normal volume.

It is also exactly the shape of an impatient OTP user. Someone who taps "Resend code" three times in ten seconds will trip it, and your workflow will report failures for a user who is doing nothing unusual. Build the cooldown into your own UI - disable the resend button for 60 seconds - rather than discovering the platform's limit through failed sends.

The API call ceiling: 200 requests per hour by default

The Cloud API's default is 200 requests per hour per app per WABA, rising to 5,000 per hour once the WABA has at least one registered phone number. A workflow that polls, checks status, or makes several calls per OTP can consume that faster than the message count suggests. Count API calls, not just messages.

And the tier that caps your launch

Business-initiated messaging is capped by tier at 250 unique customers per rolling 24 hours for a new account, rising through 2,000, 10,000, 100,000 and unlimited. The cap counts unique customers, and it is shared at business portfolio level across every number in it - a second number does not double your capacity. For OTP that means a launch day with 400 new signups fails partway through at the starting tier, which is a genuinely bad day to discover the limit. Quality-driven restrictions like 131048 apply on top and cannot be retried away.

The last row is the one worth pausing on. Authentication and marketing templates share a phone number, a quality rating and a messaging tier. A marketing campaign that generates blocks and reports can degrade the number your login flow depends on - and an account restriction takes the OTP channel down with it. If OTP is load-bearing for your authentication, keep it on a number that is not also running campaigns.

n8n is a very good fit for the shape of work described here: a trigger, a template send, a store write, a response. It is a workflow engine, and OTP is a workflow.

It is a poor fit the moment WhatsApp becomes a conversation. Support threads need window-state tracking per contact, template fallback when the window closes, agent handoff, conversation history, and a per-contact view that survives across executions. Modelling that as workflow nodes means rebuilding a messaging platform in a tool designed for pipelines - and doing it while also owning token rotation, retry semantics and rate pacing.

Conferbot's WhatsApp integration sits on the same official Cloud API and handles that layer: you connect a number, build the conversation visually, and the platform decides whether a message can go free-form or needs a template. The same flow runs on Telegram, Instagram, Messenger and a website widget without a rewrite. There is no native n8n connector, but conversations hand data out through the built-in integrations - Webhook and Zapier among them - or the API, so an n8n workflow can sit on either side of a Conferbot flow via a plain HTTP call.

Conferbot's free tier includes 600 conversations a month, 1 bot and 2 seats, with no credit card required. It is a free tier rather than a trial - it does not expire and nothing switches off after 14 days - so you can run a real WhatsApp conversation flow alongside your n8n OTP workflow and see which half belongs where. Pricing covers the step up when volume grows.

Whichever way you build it, get the cost model right before launch. The API is free, the tooling is free, the test number is free - and every verification code is a line item from the first one. The free WhatsApp API guide covers the setup side end to end.