Webhook 是什麼？Webhook 是「事件發生就通知」的串接方式：你先把自己伺服器上的一個網址（Webhook 網址）登記在對方平台，當付款完成、使用者傳來訊息或資料被修改時，對方系統就主動對這個網址送出 HTTP 請求，帶來事件內容。它和一般 API 的方向相反，API 是你去問對方，Webhook 是對方來告訴你，因此不必反覆輪詢就能近乎即時反應。串接時要準備公開的 HTTPS 網址、驗證請求確實來自對方、盡快回應成功狀態碼，並處理重送造成的重複事件。
Webhook 的運作方式：登記網址、事件觸發與回應
- 登記網址：在對方平台的設定頁填入 Webhook 網址，部分平台會先送驗證請求確認網址可用。
- 事件發生：以 LINE 的 Messaging API 為例，使用者加好友或傳訊息時，LINE 平台會對登記的網址送出含事件物件的 HTTP POST 請求。
- 接收端回應：伺服器收到後回傳成功狀態碼。MDN 把二開頭的狀態碼定義為成功回應；以 Microsoft Graph 的變更通知為例，三秒內收到二開頭的回應才算送達。
- 後續處理：依事件內容更新訂單、寫入資料庫或發送通知。
Webhook 送來的不一定是完整資料。Microsoft Graph 的基本通知只帶變更資源的識別碼，接收端要再用這個識別碼呼叫 API 取回內容；有些資源才支援附上資料本身的通知。規劃時先看文件確認事件欄位。
Webhook 和 API 輪詢差在哪
輪詢是每隔一段時間呼叫一次對方的 API，問「有沒有新資料」。Microsoft 說明變更通知採事件驅動模式，有變更才通知，取代反覆輪詢；適合資源經常變動、需要近乎即時反應，或想避免頻繁輪詢而觸發節流限制的情境。API 的基本概念可先看API 是什麼。
| 比較項目 | API 輪詢 | Webhook |
|---|---|---|
| 誰發起請求 | 你的系統定時詢問 | 對方系統在事件發生時通知 |
| 即時性 | 取決於輪詢間隔 | 事件發生後送出 |
| 請求量 | 沒有新資料也要一直問 | 有事件才送 |
| 接收端需求 | 能呼叫對方 API 即可 | 要有公開的 HTTPS 網址 |
| 漏接的風險 | 下次輪詢會補上 | 依賴對方重送，可能漏接 |
兩者可以並用：平時靠 Webhook 即時更新，再定期呼叫 API 對帳，補回漏接的事件。
Webhook 網址要符合的條件
- 公開且使用 HTTPS：Microsoft Graph 要求端點可公開存取並以 HTTPS 保護；LINE 要求 Webhook 網址使用 HTTPS 並具備 SSL／TLS 憑證，不接受自簽憑證。
- 能通過驗證：Microsoft Graph 建立訂閱時會送出驗證權杖，端點要在十秒內以純文字回傳解碼後的權杖，否則訂閱不會建立；LINE 則在設定頁按「Verify」測試網址。
- 網址本身要保密：Google Chat 的傳入 Webhook 網址含有必須保密的權杖，官方提醒不要公開分享，例如放進公開的程式碼存放庫。
測試網址與正式網址分開，上線前再切換，避免測試資料寫進正式系統。
常見用途：金流、表單、LINE 與 Teams
金流付款結果通知
金流業者若提供付款結果的伺服器通知，網站就能在付款完成後自動更新訂單狀態。收到通知要先驗證簽章，不能只看通知裡的付款狀態，細節見金流串接的資安重點。
表單送出後通知團隊
官網的詢價或報名表單送出後，由網站對 Teams 或 Google Chat 的傳入 Webhook 送一則訊息，業務就能在群組即時看到。Google Chat 的傳入 Webhook 是單向的，不支援對話，需要可存取 Google Chat 的 Business 或 Enterprise 版 Google Workspace 帳戶，機構也要允許使用者新增及使用傳入 Webhook。
LINE 官方帳號接收訊息
LINE 的 Webhook 教學步驟是：先準備頻道存取權杖（Bot 呼叫 Messaging API 時需要），再到 LINE Developers Console 點選提供者與 Messaging API 頻道，進入「Messaging API」分頁，在 Webhook URL 下按「Edit」輸入網址後按「Update」，再按「Verify」看到「Success」，接著開啟「Use webhook」。會員綁定與推播的規劃見LINE API 串接。
Teams 的傳入 Webhook
Microsoft 說明 Microsoft 365 連接器已接近淘汰，Teams 的「工作流程」是更有彈性與安全的做法：選擇 Webhook 範本、指定團隊與頻道後儲存，在工作流程詳細資料頁按「複製 Webhook URL」。工作流程只連結到擁有者，沒有共同擁有者可能變成無人管理的流程，記得指定共同擁有者。
安全驗證：確認請求真的來自對方
任何人只要知道網址都能對它送請求，所以接收端不能收到就照做。LINE 的做法是在 x-line-signature 標頭放入簽章，接收端用頻道密鑰對收到的原始請求內容計算 HMAC，結果一致才處理，不一致或沒有簽章就拒絕。LINE 提醒驗證前不要先解析或改寫內容，連代理伺服器也不能動到；LINE 不公開平台的 IP 位址，不要依賴 IP 白名單。Microsoft Graph 則要求訂閱時設定 clientState，收到通知時比對，不一致就視為無效。頻道密鑰這類值和 API 金鑰一樣要妥善保管，不寫進前端程式。
重送、重複與順序：接收端要能重複處理
MDN 對冪等的定義是，送出一次與送出多次相同請求，對伺服器的預期效果相同，並指出 POST 不一定具備冪等性。LINE 與 Microsoft Graph 的 Webhook 都以 POST 送出，接收端要自己做到重複收到也不出錯：
- 用事件編號去重：LINE 說明同一事件可能送達不只一次，可用 webhookEventId 判斷是否處理過。
- 不依賴到達順序：LINE 指出重送後的順序可能與實際發生順序不同，必要時看事件的時間戳記。
- 先回應、再處理：Microsoft Graph 建議來不及在三秒內處理時，先驗證並放入佇列，回傳 202 表示已收到；MDN 對 202 的定義正是已收到、尚未處理。
- 了解重送規則：Microsoft Graph 未送達的通知會以指數退避持續重試，至多四小時；LINE 的重送功能要另外開啟，次數與間隔未公開，也不代表一定送達。
常見問題
Webhook 中文怎麼說？
沒有統一的中文譯名，Microsoft 與 Google 的繁體中文文件都直接寫 Webhook，例如「傳入 Webhook」。可以把它理解成對方系統在事件發生時呼叫的通知網址。
Webhook 和 WebSocket 一樣嗎？
不一樣。MDN 說明 WebSocket 是在瀏覽器與伺服器之間開啟雙向互動的連線；Webhook 是一方系統在事件發生時，對另一方的網址送出一次 HTTP 請求。
沒有自己的伺服器也能接收 Webhook 嗎？
接收端需要能公開存取的 HTTPS 網址。只是要把通知送進聊天群組時，可以用 Teams 工作流程或 Google Chat 產生的傳入 Webhook 網址，不必自己架設接收程式。
Webhook 一直收不到通知，要從哪裡查？
先用平台的驗證功能測試網址，再檢查伺服器是否回傳成功狀態碼、憑證是否有效、防火牆或主機規則有沒有擋下請求，並查看接收端的錯誤紀錄。
Webhook 網址外流了怎麼辦？
立即停用外流的網址並建立新的，平台能重新發行密鑰的也一併更換，再檢查外流期間收到的請求是否都通過驗證，必要時刪除可疑資料。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
導入 Webhook 前，先列出要接的平台、需要的事件與欄位、失敗時由誰處理。京采的網頁設計服務可以協助規劃官網與後台的 Webhook 接收端，包含 HTTPS 網址、簽章驗證、去重與錯誤紀錄，並在測試環境跑完重送與失敗情境再上線。想把表單、金流或 LINE 通知串進現有系統，歡迎與我們聯繫。
