Connect WhatsApp to n8n on the official Cloud API

How does a WhatsApp message reach an n8n workflow?

Meta delivers every message sent to the number to a single URL that you nominate, as an HTTP POST. That URL is the entire integration. Put an n8n Webhook node at a production URL, set it as the number's webhook destination, and the workflow runs on every inbound message.

The payload carries the sender, the text or media reference, a timestamp and the message id. From there it is an ordinary n8n workflow: branch on the content, look the customer up, call whatever else you run, and decide whether to reply.

Because this is Coexistence, the same message is also sitting in the WhatsApp Business app on the phone. A human can answer it. The workflow sees what the human sent, and the human sees what the workflow sent, so neither replies on top of the other.

{
  "from": "14155550188",
  "id": "wamid.HBgLMTQxNTU1NTAxODgVAgAS",
  "timestamp": "1758412800",
  "type": "text",
  "text": { "body": "do you have anything friday?" }
}

How does the workflow send a reply?

With an HTTP Request node against the Cloud API, using the number's phone number id and access token. Both are readable from the dashboard, or through the MCP connector if you would rather an assistant fetch them.

What to send depends on timing, and this is the part that catches people. Inside 24 hours of the customer's last message, free text works and the reply is whatever the workflow composed. Outside that window, only a template Meta has already approved will go through. A workflow that only ever sends free text looks perfect in testing, because testing always happens seconds after a message, and then goes quiet on the first real overnight case.

The robust shape is a branch: check how long ago the last inbound message was, and pick free text or a template accordingly.

Can n8n use the MCP connector as well?

Yes, and n8n is unusual in this. Its MCP Client Tool node connects out to a remote MCP server and supports OAuth2, which is what ours needs, so an AI Agent node in a workflow can call our tools directly.

That is worth knowing because most automation platforms cannot. Make and Zapier both run MCP servers of their own and neither acts as a client, so neither can reach a third party server. n8n can.

What it is good for is the acting half: an agent node that decides to send a message, check a number's health, or read back a template's approval status while a workflow is running. What it cannot do is replace the webhook, because MCP has no way to be woken by an incoming message.

Which of the two should a workflow use?

Both, for different halves, and the split is not a preference.

The webhook is how anything starts. A customer writes, Meta delivers to your Webhook node, the workflow runs. There is no MCP equivalent of that in any tool, because the protocol is request and response rather than something that can be called into.

The MCP Client Tool is for an agent inside that workflow to act without you hardcoding the call. If the workflow already knows exactly what to send, an HTTP Request node against the Cloud API is simpler and has less to go wrong. If an agent is deciding, the connector gives it the eleven tools and the rules that come with their descriptions, including the 24 hour window.

What makes this different from the n8n WhatsApp nodes people already use?

Most n8n WhatsApp setups you will find in the wild are built on an unofficial gateway that signs in as a linked device. They are easy to start and they put the number at risk, because that mechanism breaks WhatsApp's terms and Meta detects the traffic pattern rather than the library.

The other common route is the official API without Coexistence, which works but migrates the number. The WhatsApp Business app stops functioning on it, and the team that was answering all day has to move into a new tool. For most small businesses that is a non-starter, which is why so many of them ended up on unofficial gateways in the first place.

Coexistence is the combination that was missing. Official API, and the phone keeps working.

Common mistakes

• Using an n8n Test URL as the webhook destination. It stops listening when the editor closes, so messages are delivered to nothing.
• Not answering Meta's verification request. Meta sends a GET with a challenge before it delivers anything, and a node that does not echo it back never receives a message.
• Replying with free text outside the 24 hour window. It fails silently from the workflow's point of view, and only an approved template goes through.

Frequently asked questions

Keep reading