在官方 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 和存取權杖。兩者都可從控制台讀取，或者如果您希望由助理提取，也可透過 MCP 連接器讀取。

要傳送的內容取決於時間，這正是最容易出錯的地方。在客戶最後一則訊息後 24 小時內，可以使用免費文字，回覆內容由工作流程組成。超過此時限後，只有 Meta 已批准的訊息範本可以送出。只傳送免費文字的工作流程在測試時看似完美，因為測試總是在訊息後幾秒內進行，到了第一個真正的隔夜個案便會停止回應。

穩健的做法是加入分支：檢查最後一則傳入訊息距今多久，再相應選擇免費文字或訊息範本。

n8n 也可以使用 MCP 連接器嗎？

可以，而 n8n 在這方面相當少見。它的 MCP Client Tool 節點會連接到遠端 MCP 伺服器，並支援 OAuth2，這正是我們所需的功能，因此工作流程中的 AI Agent 節點可以直接呼叫我們的工具。

這一點值得注意，因為大部分自動化平台都做不到。Make 和 Zapier 都會自行執行 MCP 伺服器，兩者都不會作為用戶端，因此都無法連接第三方伺服器。n8n 可以。

它適合處理的是執行部分：工作流程運行期間，由代理程式節點決定傳送訊息、檢查號碼狀況，或讀取訊息範本的批准狀態。它無法取代 Webhook，因為 MCP 沒有方法因應傳入訊息而被喚醒。

工作流程應該使用哪一個？

兩者都要，分別處理不同部分，這並非偏好問題。

Webhook 是一切開始的方式。客戶發出訊息，Meta 將訊息傳送到您的 Webhook 節點，工作流程便會執行。任何工具都沒有 MCP 的對應方式，因為該協定是請求與回應，而不是可以被呼叫進入的機制。

MCP Client Tool 是讓工作流程內的代理程式執行操作，而不必由您硬編碼呼叫。如果工作流程已確切知道要傳送的內容，使用 HTTP Request 節點呼叫 Cloud API 會更簡單，出錯的地方也較少。如果由代理程式作決定，連接器會提供 11 個工具，以及工具描述中附帶的規則，包括 24 小時時限。

這與人們已在使用的 n8n WhatsApp 節點有何不同？

您在實際環境中找到的大部分 n8n WhatsApp 設定，都是建基於以連結裝置身分登入的非官方閘道。它們容易開始使用，卻會令號碼面臨風險，因為這種機制違反 WhatsApp 條款，而 Meta 偵測的是流量模式，不是所使用的程式庫。

另一條常見路徑是不使用 Coexistence 的官方 API。它可以運作，但會遷移號碼。WhatsApp Business 應用程式會停止在該號碼上運作，而原本整天負責回覆的團隊必須轉移到新工具。對大部分小型企業而言，這不可接受，因此許多企業最初才會選擇非官方閘道。

Coexistence 正是缺少的組合：官方 API，同時保留手機的正常運作。

常見錯誤

• 使用 n8n Test URL 作為 Webhook 目的地。編輯器關閉後，它便會停止監聽，訊息也就無人接收。
• 沒有回應 Meta 的驗證請求。Meta 會先以 GET 傳送挑戰值，然後才傳送其他內容；如果節點沒有原樣回傳挑戰值，便永遠收不到訊息。
• 在 24 小時時限以外使用免費文字回覆。從工作流程角度看，這會無聲無息地失敗，只有已批准的訊息範本可以送出。

常見問題

繼續閱讀