通过官方 Cloud API 将 WhatsApp 连接到 n8n

WhatsApp 消息如何进入 n8n 工作流？

Meta 会通过 HTTP POST，将发送到该号码的每条消息传送到您指定的单个 URL。这个 URL 就是整个集成。将 n8n Webhook 节点放在生产 URL 上，把它设置为该号码的 Webhook 目标，工作流就会在每条收到的消息到达时运行。

负载包含发送者、文本或媒体引用、时间戳和消息 id。接下来就是普通的 n8n 工作流：按内容分支、查询客户、调用您运行的其他服务，并决定是否回复。

由于这是 Coexistence，同一条消息也会出现在手机上的 WhatsApp Business 应用中。人工可以回复。工作流能看到人工发送的内容，人工也能看到工作流发送的内容，因此双方不会互相覆盖回复。

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

工作流如何发送回复？

使用 HTTP Request 节点调用 Cloud API，并提供该号码的 phone number id 和 access token。这两个字段可以从控制台读取，也可以通过 MCP connector 获取，交由助手代为查询。

要发送什么取决于时间，这是最容易出错的部分。在客户最后一条消息后的 24 小时内，可以使用自由文本，回复内容由工作流自行编写。超过这个时间窗口后，只有 Meta 已批准的模板才能发送。只发送自由文本的工作流在测试时看起来一切正常，因为测试总是在消息发出几秒后进行，但第一次真正的隔夜场景就会停止响应。

稳妥的做法是设置分支：先检查最后一条收到的消息距今多久，再相应选择自由文本或模板。

n8n 也能使用 MCP connector 吗？

可以，而且 n8n 在这方面很少见。它的 MCP Client Tool 节点可以连接远程 MCP server，并支持 OAuth2，这正是我们的连接器所需的功能。因此，工作流中的 AI Agent 节点可以直接调用我们的工具。

这一点值得注意，因为大多数自动化平台无法做到。Make 和 Zapier 都运行自己的 MCP server，但都不能充当客户端，因此都无法连接第三方 server。n8n 可以。

它适合处理执行部分：工作流运行时，由 agent 节点决定发送消息、检查号码的连接状态，或读取模板的审批状态。它不能取代 Webhook，因为 MCP 没有办法因收到消息而被唤醒。

工作流应该使用哪一个？

两者都要用，但分别负责不同部分，这不是偏好问题。

Webhook 负责启动流程。客户发来消息，Meta 将消息传送到您的 Webhook 节点，工作流随即运行。任何工具都没有 MCP 的对应功能，因为该协议采用请求和响应模式，不能被主动调用来接收事件。

MCP Client Tool 用于让工作流中的 agent 执行操作，而无需您把调用逻辑硬编码进去。如果工作流已经明确知道要发送什么，使用 HTTP Request 节点调用 Cloud API 更简单，出错点也更少。如果由 agent 做决定，连接器会提供 11 个工具及其说明中的规则，包括 24 小时窗口。

这与人们已经在使用的 n8n WhatsApp 节点有什么不同？

您在实际使用中看到的大多数 n8n WhatsApp 设置，都建立在非官方网关上，并以已连接设备的方式登录。这些方案容易开始使用，却会让号码面临风险，因为这种机制违反 WhatsApp 的条款，Meta 检测的是流量模式，而不是所用的库。

另一条常见路线是不使用 Coexistence 的官方 API。它可以运行，但会迁移号码。WhatsApp Business 应用会在该号码上停止工作，原本全天回复消息的团队必须转移到新工具。对大多数小型企业来说，这不可接受，所以许多企业最初才会使用非官方网关。

Coexistence 补上了缺失的组合：使用官方 API，同时保留手机上的应用。

常见错误

• 将 n8n Test URL 用作 Webhook 目标。编辑器关闭后，它就会停止监听，消息也就无处投递。
• 没有响应 Meta 的验证请求。在开始投递消息前，Meta 会发送带有 challenge 的 GET 请求；如果节点没有原样返回它，就永远收不到消息。
• 在 24 小时窗口外使用自由文本回复。从工作流角度看，这通常会静默失败，只有已批准的模板才能发送。

常见问题

继续阅读