使用 Node.js 傳送及接收 WhatsApp
接收是由路由回應 Meta 的驗證 GET 請求，並接受 POST 請求。傳送則是使用 fetch 呼叫 Cloud API，附上號碼的 phone number id 及存取權杖。不需要我們的 SDK，也無需安裝任何軟件。
如何在 Node.js 接收訊息？
使用一個包含兩種方法的路由，可在 Express、Fastify、Next 路由處理常式或普通伺服器中運作。
GET 會回應 Meta 的驗證：從查詢讀取 hub.mode、hub.verify_token 及 hub.challenge，將權杖與您的權杖比較，然後以純文字回傳 challenge。以 JSON 回傳是最常見的錯誤，會令端點看似正確，卻永遠收不到任何內容。
POST 會接收事件。立即回應 200，之後才處理。Meta 會重試任何處理緩慢的請求，而在回應前完成工作的處理常式會多次看見同一則訊息。尤其在無伺服器環境，先回應再將工作放入佇列，才能避免冷啟動造成重複處理。
如何傳送？
使用 fetch 呼叫 phone number id 對應的 Cloud API `messages` 端點，並在 bearer 標頭中附上存取權杖。
這件事沒有任何部分是我們專有的，因此請求完全符合 Meta 的官方文件，您不需要學習或受制於任何包裝層。兩個值都在控制台中；如果由助理負責接線，get_api_credentials 會透過 MCP 連接器回傳它們。
請根據時間決定內容。客戶最後一次傳入訊息後 24 小時內，傳送 text 物件。超過時限，則傳送包含已核准範本名稱及語言的 template 物件。只傳送文字的程式碼能通過所有測試，卻會在第一則夜間抵達的訊息上失敗。
無伺服器環境有何不同？
有兩點，而且都與函式在工作完成前結束有關。
回應 200 後繼續處理，無法在函式一回應便立即凍結的情況下運作。請使用平台提供的機制，讓回應後的工作繼續執行；或將負載推送至佇列，再由另一個函式處理。Meta 只需要您快速確認收到，不需要工作當刻完成。
冷啟動也會令回應變慢，帶來更多重試及重複訊息。在這種架構中，按 wamid 訊息 id 去除重複並非可有可無，而是可靠運作的必要條件。
常見錯誤
- 將 challenge 以 JSON 回傳，而非回傳原始內容。
- 在回應 200 前先處理工作。無伺服器環境下，函式可能在回應時立即凍結。
- 略過去除重複。Meta 會按設計重試，重複訊息是正常情況，而非例外。
在 easycoexistence.com 連接號碼，將 Webhook 目的地設定為您的路由，再從控制台讀取 phone number id 及存取權杖。每個號碼每月 US$ 9 起，用量大時降至 US$ 2，首 7 天免費試用。
常見問題
需要程式庫嗎？
不需要。一個路由及 fetch 已經足夠，而且請求完全符合 Meta 的官方文件。
可在 Vercel 或 Lambda 上運作嗎？
可以，但要注意一般無伺服器限制：先確認收到，再透過佇列或背景機制處理，不要在請求內直接處理。
如何驗證請求確實來自 Meta？
使用您的應用程式密鑰，核對簽名標頭。端點公開後，這項檢查應立即加入。
可以使用 TypeScript 嗎？
可以。我們沒有需要進行型別定義的內容，因為負載屬於 Meta，且由 Meta 提供文件。
繼續閱讀
準備開始嗎？
幾分鐘內設定 WhatsApp Coexistence，而非幾個月。應用程式在手機上仍可繼續運作。
開始免費試用驗證日期