WhatsApp Business API 在 n8n 的自動化：先從 24 小時服務窗口開始

Every few weeks a small business owner tells me the same thing: "We get hundreds of WhatsApp messages and we answer them by hand. Can you automate it?" The honest answer is yes, partly, and the part you automate matters more than the tool you pick. I have watched more than one WhatsApp bot idea die because it was designed as a chatbot first and a messaging channel second.

WhatsApp business API automation has rules that web chat doesn't. There is a clock on every conversation, there is pricing per delivered message, and there are template messages that need approval before you can send them cold. If you wire up a flow in n8n without those in your head, you will build something that works on your own phone and falls over on the third real customer.

This is the order I'd tackle it in now: rules first, then the workflow, then where a language model fits, and where it shouldn't. I'm describing the shape here, not a finished product, and I'll flag the places where I'm relying on documentation I couldn't fully read.

Start from the 24-hour window

The single most useful fact about the platform is the customer service window. According to the WhatsApp Business Platform pricing page, when a user messages a business it opens a 24-hour window in which the business can reply with service messages at no charge, and the window resets with each new user message.

That sentence should drive your design. Inside the window you can send free-form replies, which is where an AI draft or an automated answer is natural. Outside it, you can only start a conversation with an approved template message, and that category of message is billed.

So the first question for any automation is: does this flow answer people, or does it start conversations? Answering is cheap and conversational. Starting conversations is a marketing and compliance decision that deserves its own planning. I build the answering flow first because it has a clear boundary, and the customer already asked for the interaction.

What you actually pay for

I'd rather you read the pricing page yourself than trust my summary, but the structure is worth knowing before you promise a client a monthly figure. The same page says businesses are charged per message delivered (not sent), rates depend on the destination market and the message category, and there are four categories: marketing, authentication, utility and service. It also says service messages are not charged, and that messages in the three days after a customer arrives through an ad that clicks to WhatsApp are free.

Pricing models like this have changed more than once, and the page I read is the one that applies today, not necessarily next quarter. When I quote automation work I give the client a range, tell them where to look up the current rates for their country, and keep the platform fees on a separate line from my own fee. Rolling them together makes my quote look wrong every time Meta changes a number.

A small n8n shape that works

The pattern I use is boring on purpose. A webhook receives the incoming message. A short chain of nodes decides what kind of message it is. One branch answers common questions from a fixed source, and another branch hands the conversation to a human.

n8n has a built-in WhatsApp Business Cloud node whose documented operations include sending a message, sending a template, a send-and-wait-for-response operation, and uploading, downloading and deleting media. For receiving messages you pair it with a webhook. Meta's webhook guide is where the handshake and payload format live. I can't reproduce those details with confidence because that page renders in the browser and I'd rather you read it than copy my paraphrase.

Two things I always add, because webhook senders in general retry and attackers in general guess URLs.

First, verify that the request came from Meta. Incoming requests carry a signature header you can check against your app secret. In an n8n Code node the check looks roughly like this:

const crypto = require('crypto');

const secret = $env.WHATSAPP_APP_SECRET;
const received = $json.headers['x-hub-signature-256'] || '';
const expected = 'sha256=' + crypto
  .createHmac('sha256', secret)
  .update($json.rawBody)
  .digest('hex');

const ok = received.length === expected.length &&
  crypto.timingSafeEqual(Buffer.from(received), Buffer.from(expected));

if (!ok) throw new Error('bad signature');
return $input.all();

The hard part is rawBody. The signature is computed over the exact bytes Meta sent, so a node that parses the JSON and re-serialises it gives you a different string and a check that always fails. Turn on the raw body option in the Webhook node settings and test with a real message, not a hand-made curl request.

Second, deduplicate. If your workflow is slow and the sender decides it hasn't heard back, you can see the same message twice. I store each message ID in a small Postgres table and skip anything already seen:

INSERT INTO wa_seen (message_id) VALUES ($1)
ON CONFLICT (message_id) DO NOTHING
RETURNING message_id;

If the insert returns no row, the flow stops. That one query is what stops a customer getting the same reply twice. I wrote about a nastier n8n failure, where a quiet bug cost a client days, in my n8n workflow post. The lesson there applies here: log every message ID and every branch decision, because you will need that log.

Where a language model fits

A model is good at one WhatsApp job: reading a messy customer message and drafting a reply from a source you control, such as an FAQ page or a price list. It is bad at deciding things the business is accountable for, like refunds, delivery promises or anything legal.

My rule is that the model drafts and a person sends, until the numbers say otherwise. The n8n docs describe a send-and-wait operation that pauses the workflow until a person approves or provides input, and the same page notes the node can serve as a human review step for AI agent tool calls. That fits this pattern directly: the draft goes to a staff member on WhatsApp, they tap approve or edit it, and only then does the customer see it.

After a few weeks of watching approvals, you'll know which question types are approved almost untouched. Those are the ones you can move to automatic replies. Everything else stays in review. If the idea of judging whether an agent is good enough makes you uneasy, I wrote up a method in grading the database, not the reply, and it carries over to chat flows.

What to leave out of version one

Leave out cold outreach. Leave out the model answering anything about money or health. Leave out clever intent classifiers until you have a few hundred real messages to look at. Version one should do three plain things: receive, answer from a fixed source inside the window, and hand off to a human with the full thread attached.

I'd also leave out voice notes and images at first. They are common on WhatsApp, and they'll arrive anyway, so your flow needs a polite fallback that says a person will look at it soon. Media handling is a good second project, once the text flow is quiet.

When not to automate at all: if the business gets thirty messages a day and one person answers them well, a bot costs more attention than it saves. Automation pays back when volume is high and questions repeat.

Build this first

This week, take one real client or your own business and export fifty recent WhatsApp conversations. Sort the first messages into groups by what the customer wanted. If one or two groups cover most of the volume, you have a scoped automation. Write the three answers those groups need, put them in a table, and build the receive-verify-deduplicate-answer chain in n8n against Meta's test number. Show a human the drafts before anything is sent. If you want help turning that into a production flow for your own business, my other automation projects are listed on my portfolio.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.