Webhook 是什麼？跟 API 差在哪？
// 一句話回答
Webhook 是一種「事件一發生，就自動主動通知你」的機制。跟一般要你「主動去問」的做法相反：webhook 是「有事它自己來敲門」。例如有客人下單，系統就立刻透過 webhook 通知你的另一個系統去出貨、記帳，全程不需要有人盯著。
先看兩種做法的差別
想知道「有沒有新消息」，有兩種做法。第一種是「主動一直去問」：每隔一段時間就問一次「有新的了嗎？」——這叫「輪詢（polling）」，像你每分鐘手動刷新一次收件匣。
第二種反過來：「有新消息時，對方主動推給你」——這就是 webhook，像手機設定好，一有新信就自動跳通知，你不必一直去看。
輪詢很費力又常常白問；webhook 即時又省力。所以要做「即時、自動」的串接，webhook 是常見的選擇。
Webhook 到底是什麼
具體來說：你先給對方一個網址（相當於「你家的門牌」），並約定「當某個事件發生時，就往這個網址送一則通知」。
之後只要那個事件一觸發（有人付款、有人填表），對方的系統就自動把一則訊息「送到你的門口」，你的系統收到後就接著做該做的事。整個過程不需要有人盯著。
用生活比喻
想像你在等一件缺貨商品到貨。輪詢＝你每天打電話問店家「到了沒？」，很煩。Webhook＝你留電話給店家，到貨時店家主動打給你。
Webhook 就是那個「到貨自動通知」：把主動權從你這邊，交給「事件發生的那一方」。
這個比喻也預告了它的弱點：如果你當下沒接到電話，訊息就可能漏掉。所以後面「三個坑」那一段，講的其實都是「漏接與重複接」怎麼處理。
設定一個 webhook，實際要填什麼
多數服務的後台都有 webhook 設定頁，欄位大同小異。看懂這幾格，你自己就能設一半：
- 接收網址（Endpoint URL）：對方要把通知送到哪。這是「你這邊要準備好的門牌」，通常由工程師或自動化平台提供
- 訂閱哪些事件：勾選你要被通知的事件，例如「付款成功」「訂單取消」「退款完成」。只勾你真的要處理的，多勾只會製造雜訊
- 密鑰（Secret）：一段只有雙方知道的字串，用來驗證「這則通知真的來自對方」。這一格請務必設定，理由見下一段
- 測試送出：多數服務提供「送一則測試通知」的按鈕。設定完一定要用它驗證一次，不要等真的有訂單才發現沒接到
常見用途
- 金流：客人付款成功，webhook 立刻通知你的系統去出貨、開發票
- 電商：新訂單進來，自動同步到你的 ERP 或倉儲
- 表單：有人填了表單，自動通知負責的同事或建立一筆資料
- 聊天機器人：使用者傳訊息，webhook 把訊息推給你的程式去回覆
- AI 流程：某個檔案上傳完成，webhook 觸發 AI 自動去讀取、分類、摘要
三個一定會遇到的坑
這一段是實際導入時最值錢的部分。webhook 看起來單純，但這三件事沒處理好，就會出現「有付款卻沒出貨」或「同一張單出了兩次」這類事故：
- 同一則通知可能送不只一次：如果對方沒收到你的成功回覆，它會重送。所以你的系統必須做到「同一筆事件處理兩次，結果要一樣」，例如先檢查這筆訂單是不是已經處理過。這件事有個名詞叫「冪等性」，你不用記，但一定要跟工程師確認有做
- 通知可能會漏掉：你的系統剛好在維護、網路不通、或程式出錯，通知就接不到。多數服務會重試幾次後放棄。所以重要流程不能只靠 webhook，要另外準備一個定期核對的機制（例如每天比對一次雙方的訂單數）
- 順序不保證：先發生的事件不一定先送到。例如「訂單建立」和「訂單付款」的通知可能顛倒抵達。程式要能處理這種情況，而不是假設順序一定正確
安全：怎麼確認通知是真的
webhook 的本質是「開一個網址讓別人往裡面送資料」。這代表任何知道這個網址的人，都可以假裝成對方送假通知——例如偽造一則「付款成功」，騙你的系統出貨。
標準的防護做法是「簽章驗證」：雙方共用一段密鑰，對方送通知時會用密鑰算出一個簽章一起送來，你這邊用同一把密鑰重算一次，對得上才處理。這就是設定頁那格 Secret 的用途。
另外三個基本原則：接收網址不要外流、只信任來自對方官方來源的通知、以及收到通知後不要照單全收，重要動作前回頭用 API 向對方確認一次真實狀態（例如收到付款通知後，再查一次這筆訂單真的付款了嗎）。
沒有工程師，可以自己設 webhook 嗎？
可以，而且比想像中容易。你需要的是「一個能接收通知的門牌」，而自動化平台（例如 Zapier、Make）就提供現成的接收網址——你把它貼進對方後台的 webhook 設定，再用拖拉的方式決定收到後要做什麼（寫進表格、發 Slack 通知、建立一筆資料）。
這條路的好處是快、不用寫程式；限制是複雜的判斷邏輯與前面講的「重複、漏接、順序」處理能力有限。適合內部通知、資料彙整這類容錯高的用途；牽涉金流、出貨這種不能出錯的流程，還是該由工程師實作並做好驗證。
對企業的意義
Webhook 讓「即時、自動」變得可能：客人一付款，後台立刻出貨、記帳、發通知，全程不用人一直盯著問。它是把多個系統串成「自動流水線」時，最常見的零件之一。
評估工具時，可以把「有沒有提供 webhook」和「有沒有 API」放在一起問。有 API 代表「你能主動去要資料」，有 webhook 代表「它能即時通知你」——兩個都有，自動化的空間才完整。
常見問題
Webhook 跟 API 差在哪？
方向相反。API 多半是「你主動去要資料」；webhook 是「有事對方主動推給你」。兩者常一起用：對方用 webhook 通知你發生了事，你再用 API 去拿詳細資料或做後續動作。
Webhook 安全嗎？
本身沒問題，但因為是「別人往你網址送資料」，要防有人偽造假通知。標準做法是用密鑰簽章驗證來源，並且在做重要動作前再回頭用 API 確認一次真實狀態。設定時務必把密鑰那一格填好。
設 webhook 一定要工程師嗎？
通常要一點技術設定（提供網址、處理收到的通知），但很多工具（金流、電商、自動化平台）都有現成介面，照著填網址即可。內部通知這類容錯高的用途可以自己來；金流、出貨這類不能出錯的，建議交給工程師。
為什麼叫 webhook？
web（網路）加上 hook（掛鉤）——意思是「在網路事件上掛一個鉤子」，事件一發生就自動觸發你設定的通知。名字本身就描述了它的行為。
同一筆訂單被處理了兩次，是 webhook 壞掉嗎？
不是壞掉，是正常行為。對方沒收到你的成功回覆時會重送，所以同一則通知可能到達多次。解法是在你這邊做「重複檢查」：處理前先確認這筆事件是否已經處理過。請跟工程師確認這一塊有做。
重要流程可以完全依賴 webhook 嗎？
不建議。通知可能因為你的系統維護、網路問題而漏接。金流、出貨這類關鍵流程，除了 webhook，還應該搭配一個定期核對機制（例如每天比對雙方的訂單資料），把漏掉的補回來。