WhatsApp Business automation with n8n: the 2026 playbook

Most "WhatsApp automation" guides skip the most important decision and go straight to the API. We won't. The first question for any messaging build is which channel your customers actually use, and the honest answer depends entirely on where they are. Get that wrong and you'll build a beautiful WhatsApp flow that reaches a third of your US list. Get it right and the rest of this playbook, the Cloud API, the templates, the AI routing, the handoff, pays for itself in the first month.

The US-first reality check: WhatsApp vs SMS vs RCS

Here is the framing that trips up American businesses copying European playbooks: WhatsApp is the default customer channel in much of the world, but the United States is the big exception. Penetration in the US sits well below half the adult population, against north of 90% in the UK, Germany, Brazil, and India. A US customer who messages "businesses on WhatsApp" every day is the exception, not the rule. Many of your American contacts simply don't have it installed, and a fair number will find an unexpected WhatsApp message from a vendor slightly off.

For a US-first audience, the practical hierarchy is:

When to use SMS/RCS (Twilio) for a US audience

Default to SMS for anything time-sensitive and universal, one-time passcodes, delivery and dispatch alerts, appointment reminders, payment confirmations. Every US phone receives SMS with no app to install, and deliverability is predictable once your A2P 10DLC registration is in place. Layer RCS (Rich Communication Services) on top where you want branded sender names, verified checkmarks, images, carousels, and read receipts, RCS Business Messaging is effectively "iMessage-grade" rich messaging that now reaches both Android and, since Apple's adoption, iPhone. Twilio exposes SMS, RCS, and WhatsApp through one Messaging API, so n8n can route a contact to whichever channel they actually support and fall back gracefully.

When WhatsApp still wins for a US business

Reserve WhatsApp for the US segments where it fits: international and cross-border customers, large immigrant and diaspora communities (Latino, South Asian, Middle Eastern, and African-American business networks lean heavily on it), travel and hospitality, and, most importantly, anyone who messaged you on WhatsApp first. If a customer opens the conversation there, that's a strong signal and a clean opt-in. The rule of thumb: in the US, let the customer pick WhatsApp; don't pick it for them. Everywhere else in this guide, WhatsApp is the lead channel because the market supports it.

Channel	Best regions / fit	Reach & rich media	Rough cost shape
SMS	US lead channel; universal everywhere	100% of phones; text + links only	~$0.005–0.04 / msg (US 10DLC) + carrier fees
RCS	US & growing; rich branded fallback to SMS	Modern Android + iPhone; images, carousels, buttons, read receipts	Per-message, near SMS; varies by carrier/provider
WhatsApp	UK, EU, LatAm, India dominant; US niche	App users only (US <~45%); media, buttons, lists, location	Per 24h conversation by category & country; service tier has free allocation

Treat that table as the routing brief, not trivia. The same n8n logic, identify the contact, classify intent, decide automation vs human, runs unchanged regardless of channel. Only the send node changes. Build the brain once and let the channel be a runtime choice. (Voice is the fourth channel; if your customers prefer to call, our AI voice agents for small business with n8n playbook covers wiring the same routing into an inbound phone agent.)

WhatsApp Business Cloud API setup: the UK/EU workhorse

For markets where WhatsApp leads, the cleanest path is the WhatsApp Business Cloud API hosted by Meta. It removes the old on-premise hosting burden, gives you the clearest visibility into template state and quality ratings, and carries the lowest platform margin because there's no provider in the middle. Twilio is the alternative when you want one vendor across SMS, RCS, and WhatsApp, or faster human support, it's the same Cloud API underneath with an abstraction on top.

Setup steps that avoid rework:

1. Create or verify a Meta Business account and a WhatsApp Business Account (WABA).
2. Create a Meta app, add the WhatsApp product, connect a phone number, and complete business verification (required to lift messaging limits beyond the starter tier).
3. Generate a long-lived system-user access token, not the 24-hour test token, and record the phone_number_id and waba_id.
4. Point the webhook callback URL at an n8n Webhook node and answer the hub.challenge verification with your verify token.
5. Subscribe to the messages and message_status (sent / delivered / read / failed) and message_template_status_update fields.
6. Store the phone number ID, WABA ID, verify token, and access token in n8n credentials or environment-backed secrets, never in the workflow JSON.
7. Stand up a message ledger (Postgres/Airtable): message ID, contact ID, direction, channel, template name, category, and delivery state.

Session messages, template messages, and what they cost

The single concept that makes WhatsApp different from SMS is the 24-hour customer service window. When a user messages your number, a 24-hour window opens during which you can reply with free-form session messages, any text, media, or interactive content, no pre-approval. The moment that window closes, you can only re-open the conversation with a pre-approved message template (also called HSM). That's the guardrail that stops WhatsApp becoming a spam channel, and it's why "treat WhatsApp like email" is the most expensive mistake teams make.

On pricing, Meta moved to per-message billing for template categories in 2025, replacing the old per-conversation model for most cases. The categories that matter:

• Utility, order updates, appointment reminders, receipts. Cheap, fast to approve, the backbone of most SMB flows.
• Authentication, one-time passcodes. Low cost, near-instant approval.
• Marketing, promotions, re-engagement. Most expensive, slowest to approve, quality-rated, and the first thing throttled if recipients block you.
• Service, your free-form replies inside the 24-hour window. These carry a generous free allocation and are effectively your cheapest conversations, which is why prompt, useful service replies beat marketing blasts on both cost and goodwill.

Per-message rates vary enormously by recipient country, a utility message to India costs a fraction of one to the UK or Germany. Budget against your real recipient mix, not a blended average, and if you go through Twilio, add their per-message margin on top. The practical optimisation: design flows so the customer messages first (opening a free service window) wherever you can, and lean on cheap utility templates for the proactive nudges.

Two-way conversations and CRM sync

WhatsApp is a stateful channel, which is exactly why it rewards CRM integration in a way SMS blasts never do. Every inbound and outbound message should land in the contact's timeline in HubSpot, Pipedrive, Airtable, or whatever system of record you run, n8n does this in the same run that handles the message, so support sees the full thread without leaving the CRM. The pattern is: on inbound, look up the contact by phone number; if they're unknown, create a lead with the WhatsApp number and the message as the first note; on every message either way, append to a "conversation" object and update last-contacted. That two-way sync is what turns automated replies into a genuine conversation history a salesperson or account owner can pick up mid-thread, and it's the difference between a bot that answers and a system that remembers.

Build 1: inbound WhatsApp: webhook → AI classify → template reply → human handoff

The first workflow is the spine of every WhatsApp build: receive an inbound message, identify the contact, let an AI classify intent, and either auto-reply or escalate to a human. The export-ready skeleton below uses an n8n Webhook node for Cloud API delivery, an AI Agent for classification, a Switch for routing, an HTTP Request to send the reply via the Cloud API graph endpoint, and a Slack alert for handoff. Secrets come from credentials/environment, never the JSON.

{
  "name": "WhatsApp Inbound — classify, reply, handoff",
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "whatsapp-inbound",
        "responseMode": "responseNode"
      },
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2,
      "name": "WhatsApp Webhook",
      "position": [240, 300]
    },
    {
      "parameters": {
        "jsCode": "const v = $json.body.entry?.[0]?.changes?.[0]?.value || {};\nconst msg = v.messages?.[0];\nif (!msg) return [];\nreturn [{ json: { wa_id: msg.from, msg_id: msg.id, text: msg.text?.body || '', phone_id: v.metadata?.phone_number_id } }];"
      },
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "name": "Normalize + dedupe",
      "position": [460, 300]
    },
    {
      "parameters": {
        "promptType": "define",
        "text": "={{ $json.text }}",
        "options": { "systemMessage": "Classify the WhatsApp message. Return JSON: {intent: sales|support|billing|human, urgency: low|med|high, summary: string}. Set intent=human if it mentions refund, legal, medical, cancellation, or anger." }
      },
      "type": "@n8n/n8n-nodes-langchain.agent",
      "typeVersion": 2,
      "name": "AI Classifier",
      "position": [680, 300]
    },
    {
      "parameters": {
        "model": "claude-sonnet-4-5"
      },
      "type": "@n8n/n8n-nodes-langchain.lmChatAnthropic",
      "typeVersion": 1,
      "name": "Anthropic Chat Model",
      "position": [680, 460]
    },
    {
      "parameters": {
        "dataType": "string",
        "value1": "={{ $json.intent }}",
        "rules": { "rules": [
          { "value2": "human", "output": 0 },
          { "value2": "billing", "output": 0 },
          { "value2": "support", "output": 1 },
          { "value2": "sales", "output": 1 }
        ] }
      },
      "type": "n8n-nodes-base.switch",
      "typeVersion": 3,
      "name": "Route by intent",
      "position": [900, 300]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "=https://graph.facebook.com/v20.0/{{ $json.phone_id }}/messages",
        "authentication": "predefinedCredentialType",
        "nodeCredentialType": "whatsAppApi",
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={\n  \"messaging_product\": \"whatsapp\",\n  \"to\": \"{{ $json.wa_id }}\",\n  \"type\": \"text\",\n  \"text\": { \"body\": \"Thanks — got it. Here's what you need: ...\" }\n}"
      },
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4,
      "name": "Send session reply (in window)",
      "position": [1120, 380]
    },
    {
      "parameters": {
        "channel": "#whatsapp-handoff",
        "text": "=:rotating_light: Human needed — {{ $json.summary }} (from {{ $json.wa_id }}). Reply in WhatsApp within the 24h window."
      },
      "type": "n8n-nodes-base.slack",
      "typeVersion": 2,
      "name": "Alert human (handoff)",
      "position": [1120, 220]
    }
  ],
  "connections": {
    "WhatsApp Webhook": { "main": [[{ "node": "Normalize + dedupe", "type": "main", "index": 0 }]] },
    "Normalize + dedupe": { "main": [[{ "node": "AI Classifier", "type": "main", "index": 0 }]] },
    "Anthropic Chat Model": { "ai_languageModel": [[{ "node": "AI Classifier", "type": "ai_languageModel", "index": 0 }]] },
    "AI Classifier": { "main": [[{ "node": "Route by intent", "type": "main", "index": 0 }]] },
    "Route by intent": { "main": [
      [{ "node": "Alert human (handoff)", "type": "main", "index": 0 }],
      [{ "node": "Send session reply (in window)", "type": "main", "index": 0 }]
    ] }
  }
}

Two things make this production-grade rather than a demo. First, the classifier drafts a route, it doesn't decide unilaterally: anything touching refunds, legal, medical, cancellation, or anger is forced to human regardless of confidence, the model should never close a regulated or high-emotion conversation on its own. Second, the reply path uses a session message because we're answering inside the 24-hour window the customer just opened; if you were re-engaging a cold contact you'd swap that node for a template send and a template-status check first.

Human handoff in under 10 seconds

The handoff is where most bots feel robotic, so make it fast and honest. Detect the trigger early (explicit "talk to a person," low classifier confidence, or a risk keyword), and in the same run do three things: send the customer a short interim acknowledgement ("One of our team will jump in shortly"), post a routed alert to Slack or Telegram with the full context and a deep link, and set a flag in the ledger that pauses the bot's auto-replies on that thread so the human and the bot don't talk over each other. Because the 24-hour service window is still open from the customer's last message, your teammate can reply with free-form session messages, no template, no delay. Sub-ten-second handoff is a routing problem, not an AI problem.

Build 2: opt-in capture and compliant broadcast

The second workflow is the one that keeps you out of trouble: capturing explicit opt-in before you ever send a proactive template, and only broadcasting to contacts who cleared that bar. This flow takes a consent event (a web form, a checkbox, a keyword reply like "JOIN"), records the consent with a timestamp and source, and then a separate broadcast leg sends an approved utility/marketing template only to opted-in, non-suppressed contacts, checking template status before it fires.

{
  "name": "WhatsApp Opt-in + Compliant Broadcast",
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "whatsapp-optin"
      },
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2,
      "name": "Opt-in event",
      "position": [240, 240]
    },
    {
      "parameters": {
        "operation": "insert",
        "table": "wa_consent",
        "columns": "wa_id, source, consent_text, opted_in_at, channel",
        "additionalFields": { "mode": "independently" }
      },
      "type": "n8n-nodes-base.postgres",
      "typeVersion": 2,
      "name": "Record consent (timestamped)",
      "position": [480, 240]
    },
    {
      "parameters": {
        "rule": { "interval": [{ "field": "cronExpression", "expression": "0 10 * * 2" }] }
      },
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1,
      "name": "Weekly broadcast trigger",
      "position": [240, 460]
    },
    {
      "parameters": {
        "operation": "executeQuery",
        "query": "SELECT wa_id FROM wa_consent c WHERE c.opted_in_at IS NOT NULL AND NOT EXISTS (SELECT 1 FROM wa_suppression s WHERE s.wa_id = c.wa_id)"
      },
      "type": "n8n-nodes-base.postgres",
      "typeVersion": 2,
      "name": "Eligible recipients only",
      "position": [480, 460]
    },
    {
      "parameters": {
        "method": "GET",
        "url": "=https://graph.facebook.com/v20.0/{{ $env.WABA_ID }}/message_templates?name=weekly_update",
        "authentication": "predefinedCredentialType",
        "nodeCredentialType": "whatsAppApi"
      },
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4,
      "name": "Check template status",
      "position": [720, 460]
    },
    {
      "parameters": {
        "conditions": { "string": [{ "value1": "={{ $json.data[0].status }}", "value2": "APPROVED" }] }
      },
      "type": "n8n-nodes-base.if",
      "typeVersion": 2,
      "name": "Only if APPROVED",
      "position": [940, 460]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "=https://graph.facebook.com/v20.0/{{ $env.PHONE_NUMBER_ID }}/messages",
        "authentication": "predefinedCredentialType",
        "nodeCredentialType": "whatsAppApi",
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={\n  \"messaging_product\": \"whatsapp\",\n  \"to\": \"{{ $json.wa_id }}\",\n  \"type\": \"template\",\n  \"template\": { \"name\": \"weekly_update\", \"language\": { \"code\": \"en\" } }\n}"
      },
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4,
      "name": "Send approved template",
      "position": [1160, 460]
    }
  ],
  "connections": {
    "Opt-in event": { "main": [[{ "node": "Record consent (timestamped)", "type": "main", "index": 0 }]] },
    "Weekly broadcast trigger": { "main": [[{ "node": "Eligible recipients only", "type": "main", "index": 0 }]] },
    "Eligible recipients only": { "main": [[{ "node": "Check template status", "type": "main", "index": 0 }]] },
    "Check template status": { "main": [[{ "node": "Only if APPROVED", "type": "main", "index": 0 }]] },
    "Only if APPROVED": { "main": [[{ "node": "Send approved template", "type": "main", "index": 0 }]] }
  }
}

The non-negotiable parts: consent is recorded with a timestamp and source so you can prove it later, the recipient query excludes a suppression list (anyone who replied STOP or blocked you), and the template status is checked before every batch so a paused or rejected template never silently fails or, worse, burns your quality rating. Honour opt-out instantly: a "STOP" inbound should write to wa_suppression in the inbound workflow before anything else runs. Production builds should also wrap both flows in a shared error workflow so a failed send pages you instead of vanishing, see our n8n error handling for production workflows guide for the retry, dead-letter, and alerting pattern.

Opt-in and consent: the compliance map (US first)

Consent law is where messaging automation goes from "marketing" to "legal exposure," and the rules differ sharply by region. Lead with the US because the penalties are the steepest and the channel mix is broadest there.

United States: TCPA (and CAN-SPAM's cousins)

For SMS and voice, your primary US channels, the Telephone Consumer Protection Act (TCPA) governs. Marketing texts and calls require prior express written consent; informational/transactional texts need at least prior express consent. The FCC's 2025 rules tightened this further: consent must be specific, opt-out requests must be honoured promptly (treat "STOP" as immediate), and a single consent doesn't cover unrelated sellers. Statutory damages run $500–$1,500 per message, which is why a clean, timestamped consent ledger isn't bureaucracy, it's your defence. WhatsApp in the US inherits the same expectation: don't message someone who didn't ask.

United Kingdom: PECR (with the UK GDPR underneath)

In the UK, the Privacy and Electronic Communications Regulations (PECR) govern marketing messages, sitting on top of UK GDPR. The default is opt-in consent for marketing texts and WhatsApp messages, with a narrow "soft opt-in" allowance for existing customers about similar products, and even then you must offer an easy opt-out every time. The ICO enforces this, and "we assumed they were fine with it" is not a lawful basis.

European Union: GDPR + ePrivacy

Across the EU, GDPR plus national ePrivacy rules require a freely given, specific, informed, unambiguous opt-in for marketing, captured before the first message and revocable as easily as it was given. You also owe transparency about what you collect and why. WhatsApp messages carrying personal data are processing under GDPR, so keep your lawful basis, your retention, and your data-flow documented, particularly if any AI step sends message content to a model hosted outside the EU.

Australia: Spam Act & Privacy Act (last)

Australia, last in priority for this audience, runs on the Spam Act 2003 (consent, sender identification, and a working unsubscribe for commercial electronic messages) and the Privacy Act / Australian Privacy Principles for the underlying data. The shape is familiar: get consent, identify yourself, honour opt-out. The same consent ledger that satisfies TCPA, PECR, and GDPR satisfies the Spam Act too, build it once.