兩套系統要互通消息，直覺上會以為得由其中一方每隔一段時間去問一次「有沒有新資料」。實際上，線上表單一送出、負責人就收到通知，付款一完成、訂單狀態就自動改成已付款，這類即時連動多半不是問出來的，而是事情一發生，對方系統就主動把資料送了過來，這套機制就是 webhook。
少了它，系統只能靠反覆查詢追新資料，查得太勤白白耗資源，查得太疏又總是慢半拍。webhook 做的，就是把「去問」換成「被通知」。
這個差別不只是工程師的事。表單通知、金流對帳、LINE 聊天機器人這些日常工具背後，都是同一套機制在傳遞資料，弄懂它，遇到資料沒進來、該不該找工程師這類判斷時，心裡就有個底。
Webhook 是什麼？
打開不少工具的整合設定頁，你常會看到一欄要求填入「Webhook URL」，這通常是許多人第一次真正碰到 webhook 這個詞的地方。這個欄位背後的邏輯其實不複雜，你提供一個網址，當某件事發生時，對方系統會自動把資料送到這個網址，你不需要主動開口去問。
Red Hat 的說明頁把 webhook 定義為一種輕量、由事件驅動的通訊方式，透過 HTTP 自動在應用程式之間傳送資料，而且由特定事件觸發。換句話說，webhook 不會在固定時間點自動送出資料，也不需要有人守在後台按下傳送鍵，它只在「某件事真的發生了」的當下才啟動。
這也是它常被稱為 reverse API 或 push API 的原因。Twilio 部落格把 webhook 說成是一個 app 在特定事件發生的當下，自動送給另一個 app 的 HTTP 請求，也稱它是 web callback 或 HTTP push API，用來讓一個應用程式即時把資訊提供給其他應用程式。Red Hat 進一步解釋，webhook 之所以叫「反向」，是因為它把通訊的責任放在伺服器端，而不是接收端。一般的 API 是由使用中的應用程式主動發出請求、等伺服器回應，webhook 則是伺服器一有資料，就主動送出一個 HTTP POST 請求過去，不用應用程式開口問。
Zapier 則從使用者在介面上實際會看到的用語切入。webhook 是應用程式在某件事發生時自動送出的訊息，帶著一包資料，業界稱它為 payload，送到的目的地就是一組獨一無二的 URL。payload 與 URL 這兩個詞，你會在很多工具的 webhook 設定頁反覆看到，先把它們對應到「送出的那包資料」與「接收的那個網址」，後面理解 webhook 的運作方式會順很多。
webhook 與 API 的差異在於主動送出資料的一方
想像你想跟朋友要一點糖，一種做法是反覆敲門問對方有沒有糖，得到的答案不一定是有；另一種是朋友一買到糖就直接送過來，不用你開口。Zapier 部落格用這個比喻，把反覆查詢和 webhook 的差別說得具體易懂。反覆查詢就是不斷敲門，每次想要都得自己去問一次；webhook 則像朋友手上一有糖，就主動送上門。
Twilio 在比較兩者的文章裡指出，兩者資料流動的方向不同，webhook 由事件驅動，事情一發生就自動推送資料，API 則由請求驅動，要有人明確提出請求才交換資料。
不過 webhook 並不是能取代 API 的獨立技術。Red Hat 特別說明，webhook 雖然有 reverse API 這類別名，本身卻不是 API，兩者是搭配運作的關係，應用程式必須先有 API，才有辦法使用 webhook。運作時也仍然需要有一個接收端存在，Twilio 對接收端的說明是，它是伺服器上一組公開可連到的網址，要能接收對方送來的 HTTP POST 請求，也就是要有一支已經寫好的程式在網址那頭等著。
兩者的效率取捨也不一樣。反覆查詢等於每隔一段時間就發一次請求，不管當下有沒有新資料都得問一次，愈頻繁查詢愈耗費資源；webhook 省去這道重複查詢的手續，但代價是你得先把接收端設定好、能穩定收下資料，不像查詢那樣想什麼時候問就什麼時候問。GitHub 的開發者文件也指出，跟反覆查詢 API 相比，webhook 需要的工作量與資源都比較少，擴展性更好，也能做到接近即時的更新。
webhook 從設定到送達的四個環節
不用寫程式，你也能理解 webhook 怎麼跑完一輪。整個流程可以拆成四個環節，而且設定好之後，你不需要再做任何額外動作，也不必時不時打開後台檢查有沒有新資料進來。
- 環節一，先在接收資料的那一端取得一個接收端網址，並登記想訂閱的事件，像是新訂單成立或有人加了好友。
- 環節二，你登記的那個事件真的在來源系統發生了。
- 環節三，來源系統自動把一小包資料送到你登記的那個網址，不需要你主動去要。
- 環節四，接收端收到資料後執行後續動作，這個接收端可能是像 Zapier 這類自動化平台，也可能是自己開發的系統。
Twilio 把這個過程講得更細。你先登記一個接收端網址，等你登記的事件真正發生，來源系統就把資料用 POST 方式送到這個網址；你的接收端要先驗證這包資料真的來自對方、不是被冒充的，再回一個 2xx 狀態碼告訴對方收到了，最後才非同步處理這個事件本身。Red Hat 描述設定步驟時也是同樣的邏輯，設定 webhook 時，要把一組獨一無二的網址交給伺服器端的 API，並指定想知道哪個事件；設定好之後，就不必再反覆查詢伺服器。
Zapier 用一個具體例子把四個環節串起來。假設你想串接一個表單工具跟一個文件樣板工具，你先在文件樣板工具那邊建好樣板，拿到這個樣板專屬的 webhook 網址，把這組網址貼進表單工具的 webhook 設定欄位。下次有人送出表單，表單工具就會把送出的資料自動送到這組網址，文件樣板工具收到後直接把資料套進樣板、產出一張完整的發票，不需要有人手動把表單資料謄到發票上。
從網路表單到 LINE 聊天機器人，都靠 webhook 串接
表單通知、訊息機器人、電商金流、AI 工具的背景任務，乍看是四種完全不相干的情境，但背後都是同一套機制在運作。它們的共通點在於，某件事發生的當下，系統就自動把資料送到你指定的網址。webhook 出現的地方，比一般印象中廣得多。
表單送出後，負責人收到通知、發票也自動產出
表單是最常見的 webhook 用途之一。在表單工具的整合設定裡貼上一組 webhook URL 之後，只要有人送出表單，資料就會自動轉發到你指定的接收端，這個接收端可能是公司內部系統，也可能是像 Zapier 這類自動化中介平台。負責的人不用再時不時打開後台去檢查有沒有新資料，表單一送出，通知就已經在路上。
前面那個 Zapier 的例子，實際用的是表單工具 Gravity Forms 與文件樣板工具 Formstack Documents。Zapier 的說明是，觸發端應用程式發生某個事件時，會把這個事件的資料序列化，送到動作端應用程式提供的 webhook 網址。放回這個例子，Gravity Forms 是觸發端，Formstack Documents 則是提供網址的動作端，每個樣板都有一組專屬的 webhook URL，表單資料送到之後，由 Formstack 套進樣板產出發票。
訂單成立與付款完成都會觸發後續作業
電商後台最常被觸發 webhook 的兩個時刻，一個是訂單成立，一個是付款完成。訂單一旦建立，電商平台就能把資料自動推給倉儲或會計系統；金流服務在扣款確認之後，也能主動通知商店更新訂單狀態、開立發票、寄出確認信。這兩個時刻串在一起，正是「事情發生後馬上被下一個系統知道」的典型例子。
Shopify 的開發者文件列出 webhook 能做到的實際用途，包括把庫存量變動的通知送給庫存管理系統與呼叫器、把訂單、退貨或退款的變動告知物流公司、把訂單資料整合進會計軟體。文件接著以 orders/create 這個主題說明運作方式，應用程式先訂閱 orders/create 這個主題，並指定一個接收端網址；之後只要有新訂單產生，Shopify 就會把包含表頭與訂單內容的這則 webhook 送到這個網址。Twilio 也列出類似的真實案例。Stripe 觸發 payment_intent.succeeded 事件時，應用程式就能釋出數位商品；Shopify 觸發 orders/create 事件時，出貨系統就能保留對應的庫存。
Stripe 的文件則從付款這一端說明 webhook 的用途，說收到 webhook 事件能幫助應用程式回應非同步發生的事，例如顧客的銀行確認了一筆付款、顧客對某筆扣款提出爭議、或是一筆訂閱付款成功扣繳。這些都是應用程式自己無法即時掌握、得靠 Stripe 主動通知才知道的時刻。
LINE 官方帳號的自動回覆仰賴 webhook 事件
在台灣，常見的 webhook 應用之一就是 LINE 官方帳號。使用者傳訊息、加好友的當下，帳號就能立刻自動回覆或轉接客服，背後靠的正是 LINE 平台把每一個互動事件即時送到店家設定好的接收端。少了這套機制，帳號就只能等人工打開後台看訊息，沒辦法做到即時互動。
LINE Developers 文件說明，只要使用者把某個 LINE 官方帳號加為好友，或是傳送訊息給它，LINE 平台就會發出一個包含 webhook 事件物件的 HTTP POST 請求，送到店家在 LINE Developers Console 登記的 webhook URL。文件也列出會觸發 webhook 的事件類型，包括使用者傳訊息的 Message event、加好友的 Follow event、封鎖的 Unfollow event，以及點擊帶有 postback 動作的按鈕所觸發的 Postback event。整體流程可以拆成三步：使用者傳一則訊息給 LINE 官方帳號；LINE 平台把這個 webhook 事件送到 bot 伺服器的 webhook URL；bot 伺服器檢查這個事件之後，再透過 LINE 平台回覆給使用者。
AI 工具在背景執行完任務後主動回報結果
這是比較新的用法，但正好對應現在不少人會碰到的情境。用 AI 工具跑一個比較花時間的任務，例如長篇的背景生成或大量資料的批次處理，不必守在畫面前等結果出來，任務做完的當下，平台就會主動把通知送到設定好的網址。背後的邏輯跟前面幾種商業情境完全一致，只是觸發事件換成了「這項工作跑完了」。目前這種用法多半用在耗時較長的背景或批次任務上。
OpenAI 的 API 文件說明，這套 webhook 讓使用者能即時收到 API 事件的通知，像是一個批次工作完成、一個背景回應生成完畢、或一個微調工作結束的時候。API 參考文件列出的事件類型，包括回應在背景完成的 response.completed、批次工作完成的 batch.completed，以及微調工作成功的 fine_tuning.job.succeeded 等事件。文件中的範例也顯示，收到通知後拿到的通常只是一個結果編號，程式還得再呼叫一次 API，用這個編號去把完整內容取回來。這代表 webhook 通知跟 API 查詢往往是搭配著用，不是互斥的兩條路，先靠 webhook 知道事情做完了，再靠 API 補查結果是什麼。
網址外流、訊息遺失，是 webhook 最常被問到的兩個疑慮
「這樣安全嗎」跟「資料會不會漏掉」，是不少企業主聽到 webhook 之後最先冒出來的兩個疑慮。這兩件事各平台都設計了對應的機制，並不是把一組網址貼上去就毫無防備。
網址被他人取得時，靠簽章驗證擋下假資料
webhook 網址本質上是公開可觸及的，只要有人知道這組網址，理論上就能自己送一包假資料進來，冒充是平台送出的正牌通知。這也是為什麼各家平台不會只靠網址本身保密來防護，而是在送出的資料裡附上一組簽章，讓接收端可以驗證這包資料真的是該平台送的、沒有被竄改過。
Twilio 提醒，webhook 是把資料送到應用程式裡公開可用的網址，存在被別人找到這組網址、進而送假資料進來的風險；對應的做法是連線一律用 TLS 加密，而如果服務商支援，就用請求簽章來驗證送進來的資料是否真的來自對方。Stripe 的文件也說明，沒有驗證的話，攻擊者可能送假的 webhook 事件到接收端，觸發出貨、開通帳號權限或竄改紀錄這類動作；因應做法是 Stripe 對每一個 webhook 事件都會簽章，簽章放在 Stripe-Signature 這個標頭裡，而且連線只接受較新版本的加密協定，也就是 TLS v1.2 與 v1.3。LINE Developers 文件同樣要求，bot 伺服器收到 webhook 事件時，要先驗證請求標頭裡的簽章，再處理事件內容，這個步驟能確認這則 webhook 真的來自 LINE 平台、傳輸過程沒有被竄改。OpenAI 也在文件中提到，建立 webhook 端點時會拿到一組簽署密鑰，應該用它驗證送進來的請求真的來自 OpenAI，特別是當這個 webhook 會在後端觸發任何實際動作的時候。
接收端當機時，多數平台會在時限內自動重試
接收端在維護或當機的那段時間，資料並不會就這樣不見。多數平台不會因為一次送達失敗就直接放棄，而是會在一段時間內自動重試，網站維護的那幾分鐘不至於讓資料永遠遺失。不過重試不是無限期的，超過各平台各自設定的時限就會停止，而且重試機制也可能讓同一筆事件被收到不只一次，這是正常現象，接收端要有辦法自己判斷重複。
Stripe 的文件給出具體數字。在正式環境下，Stripe 會嘗試遞送事件到接收端最多三天，期間採指數退避的方式拉長重試間隔；在測試沙盒環境下，則是在幾個小時內重試三次。OpenAI 的文件同樣寫明，如果接收端沒有回應成功的 2xx 狀態碼，或沒有在幾秒內回應，這個 webhook 請求就會被重試，而且 OpenAI 會持續嘗試遞送，最長可以到 72 小時，同樣採指數退避；文件也提醒，同一個 webhook 事件有可能被重複送達不只一次。LINE Developers 文件則說明，重送這個功能預設是關閉的，店家得自己到後台開啟才會生效，而且 LINE 也明講，重送的次數與間隔並不對外公開，重送功能本身也不保證一定能把 webhook 可靠地送達。Shopify 則建議應用程式不要完全依賴 webhook 送達，因為 webhook 遞送不一定保證成功，建議做法是額外設一個定期核對的作業，主動回頭跟 Shopify 對一次資料，讓應用程式的資料能保持跟 Shopify 一致。
不會寫程式也能透過中介平台收下 webhook 資料
接收 webhook 資料，不一定要自己架一台伺服器。Zapier、Make 這類自動化中介平台本身就提供現成的 webhook URL，只要把這組網址貼進來源系統的設定欄位，後續收下資料、轉發到別的應用程式，都可以交給中介平台代勞。
Zapier 的說明指出，「Webhooks by Zapier」是 Professional 方案以上內建的一個工具，選擇裡面的「Catch Hook」功能，就能接收另一個應用程式送來的 GET、POST 或 PUT 請求，Zapier 會直接給一組獨一無二的 webhook URL，把它複製起來，貼進來源應用程式設定裡的 webhook URL 欄位就完成設定。Zapier 也提到，多數情境其實不需要使用者自己動手做這一步。平台上很多應用程式背後早就在用 webhook，只是 Zapier 通常已經把實際的設定過程處理好，一般人不太會意識到。
什麼情況下還是需要工程師出馬？當你需要對送進來的資料做客製化判斷，或是要串接自己開發的系統，而不是用現成平台之間的組合，這時候還是需要有人寫程式，自己架一支能接收 POST 請求、驗證簽章、再依內容執行對應動作的接收端。中介平台能幫你跳過自己寫伺服器這一步，但沒辦法幫你決定資料進來之後，你的系統要做什麼樣的商業邏輯判斷。
多數系統會同時用上 webhook 和 API 兩種方式
該用 API 還是 webhook，取決於你需要的是「當下查一筆資料」，還是「事情發生馬上知道」。當下要查一筆資料的情境，像是結帳前確認庫存還夠不夠，適合用 API 主動去問；事情發生要馬上知道的情境，像是訂單成立、付款完成，則該讓 webhook 主動通知。
Twilio 的結論也是同一個方向。需要隨時查詢資料的情境用 API，需要即時回應事件的情境用 webhook；而且多數正式上線的系統其實兩者都會用上，API 負責在需要的時候把資料拉過來，webhook 負責在事情發生的當下把更新推送出去，不是二選一的關係。
Stripe 也示範了這種搭配的實務做法。收到 webhook 通知之後，還可以用 API 補查遺漏的物件，例如先收到 invoice.paid 這個事件，再用它帶來的資訊透過 API 把發票、扣款、訂閱這幾個物件抓回來。前面提到的 OpenAI 背景任務也是同一個模式，通知本身只帶一個結果編號，完整內容要另外呼叫 API 取回。
webhook 真正改變的是資料流動的方向，原本要有人去問才知道的事，變成事情一發生就會被通知。方向一旦反過來，要花心思的地方也跟著換了位置，不再是多久查一次，而是哪些事件值得被即時通知，資料送到之後又該由誰接手。
下次在工具的整合設定頁看到 Webhook URL 這一欄，先確認要訂閱哪個事件、由哪一方接收，再看這個服務有沒有提供簽章驗證與失敗重試。這幾件事都對上了，原本得靠人工時不時打開後台檢查的工作，就能交給系統在事件發生的當下自動完成。