Meta Tech Provider

驗證 WhatsApp Webhook 端點

在傳送任何事件前，Meta 會以帶有 hub.mode、hub.verify_token 和 hub.challenge 的 GET 呼叫您的端點。您的端點必須比較驗證權杖，並以原始內容回傳 challenge。任何其他回應都會令傳送無法開始。

必須以回應內容回傳的值。

驗證請求中 hub.mode 的值。

Meta 唯一會驗證的方案。HTTP 會在呼叫前被拒絕。

Meta 實際會傳送甚麼？

Meta 會向您的 URL 發出 GET 請求，並附帶 3 個查詢參數。hub.mode 設定為 subscribe。hub.verify_token 是您設定目的地時配置的驗證權杖。hub.challenge 是 Meta 為這次嘗試產生的值。

您的端點應比較 hub.verify_token 與您選擇的驗證權杖。兩者相符時，以 200 回應，並將 hub.challenge 作為完整回應內容。不要包裝成 JSON，不要在兩側加上引號，也不要加上某些架構預設加入的結尾換行。

如果驗證權杖不相符，請回應 403。這就是完整協定，而且刻意保持精簡。

因為驗證失敗不是您系統中的錯誤，而是 Meta 系統中缺少驗證結果。

challenge 未有正確回傳時，Meta 只是不會開始向該目的地傳送。您的伺服器會對驗證請求回應 200，記錄檔顯示請求已到達，但任何控制台都不會報告問題。唯一徵狀是訊息永遠不會到達，而大多數人會將此診斷為 Coexistence 問題，而不是握手問題。

因此，在呼叫前進行驗證很值得。我們會在發出 Graph 請求前，檢查 URL 是否使用 HTTPS，以及是否提供驗證權杖，讓格式錯誤的目的地立即失敗，而不是看起來已連接。

有 3 件與程式碼無關的事情。

端點前方設有驗證機制。閘道、基本驗證層或 IP 允許清單都會拒絕 Meta 的請求，而 Meta 沒有可提供的憑證。驗證路由必須在沒有這些憑證的情況下可到達。

重新導向。Meta 會呼叫您提供的 URL，而重新導向至標準主機的 301 不會以能完成握手的方式跟隨。請提供最終 URL。

以及會將回應序列化的架構。如果處理常式回傳的字串會被包裝成 JSON，內容就會在 challenge 兩側出現引號，因而無法相符。

使用 EasyCoexistence 完成這項設定

EasyCoexistence 會在呼叫 Meta 前驗證目的地是否使用 HTTPS 並具備驗證權杖，並在連接時間軸記錄握手失敗，而不是捨棄目的地。

我應使用哪個驗證權杖？

任何由您選擇的字串即可。它讓您的端點能分辨 Meta 的請求與其他得知該 URL 的人的請求。

驗證多久會進行一次？

設定時會進行，之後每次設定目的地時也會再次進行。正常運作的端點不會在每個事件發生時重新驗證。

我可以自行測試嗎？

可以。使用這 3 個參數呼叫您自己的端點，並確認回應內容完全等於 challenge 值。

如果我的伺服器在驗證期間停止運作，會怎樣？

握手會失敗，目的地不會啟用。再次儲存即可重新執行驗證。

幾分鐘內設定 WhatsApp Coexistence，而非幾個月。應用程式在手機上仍可繼續運作。

驗證日期 2026-09-21