為什麼你常聽到「Webhook」？
想像一下，你剛在線上商店收到一筆訂單，還沒來得及刷新頁面，庫存、發票、LINE 通知都自動幫你完成──這背後多半就是 Webhook 在搬運資料。它像門鈴，只要事件發生就「叮咚」把訊息送到指定網址，不必苦苦輪詢伺服器。這篇文章會用最生活化的方式，帶你一步步搞懂它的祕密。
Webhook 的基本概念是什麼？
- 定義
Webhook 是「使用者自訂的 HTTP 回呼（callback）」，當來源系統偵測到事件，就對你的 URL 發送 POST 請求──通常帶著 JSON 或表單資料。
簡單來說也就是「使用者自訂的網路回呼」，簡單來說，你先告訴 A 網站：某件事發生後，請幫我打給 B 網站的某個地址，然後 B 網站就能接收到這個動作並做後續處理 - 歷史
2007 年開發者 Jeff Lindsay 首次提出「Web hook」，期望把「事件驅動」帶進網路應用。en.wikipedia.org - 為何受歡迎
省去無休止的「API 輪詢」，讓整合反應時間從分鐘降到秒；對 <a href=”https://ez2.app/” style=”color:#FF7F3E”><strong>客製化平台</strong></a> 更像即時神經網路，資料一動就同步。
日常生活中的例子：
社交媒體推播通知：
假設你訂閱了某個 Instagram 用戶的動態更新。當該用戶上傳新照片或發佈新貼文時，Instagram 會使用 Webhook 通知你的應用程式或裝置，讓你即時收到推播通知，提醒你有新內容可以查看。
網站評論或回應通知：
假設你管理一個博客或線上論壇，當有讀者在你的文章下留言時，你可以設定 Webhook 在新評論提交時，將該通知發送給你或其他管理員。這樣你可以立即收到通知，快速查看和回應讀者的留言。
網購訂單通知：
當你在網上購買商品時，網站可能會使用 Webhook 在交易完成後，立即通知物流公司發送商品。這樣當付款成功或訂單狀態更動時，該網站會透過 Webhook 觸發物流系統，將發貨資訊發送給該公司進行後續處理。
行動支付通知：
當你使用行動支付（如 Apple Pay 或 Google Pay）進行線上或實體購物時，支付平台會透過 Webhook 通知商家系統，確認支付是否成功。商家系統收到這個通知後，會更新訂單狀態並安排後續處理，例如發貨或發送電子發票。
Webhook 的工作原理是什麼？
通常是一個「事件」觸發：像是你在程式碼庫裡推一次 commit、剛收到一筆訂單、或有人在部落格留言，就會立刻自動送一個請求到指定網址，讓對方網站馬上執行動作
- 事件觸發：如 Git 推送、表單送出、支付完成。
- 發送請求：來源系統以 POST 將事件 JSON 打包送往目標 URL。
- 驗證安全：常見做法是在 HTTP Header 附帶 HMAC-SHA256 簽章或 Token，接收端驗證後才處理。
- 處理回應：你的伺服器讀取 Payload，執行後續動作並回傳 2xx 確認。
Webhook 與 API 有何差異？
| 比較面向 | Webhook | 傳統 REST API 請求 | 輪詢（Polling） |
|---|---|---|---|
| 觸發方式 | 來源主動推送 | 用戶端主動拉取 | 用戶端定時拉取 |
| 傳輸時機 | 事件即時 | 依需求 | 固定間隔 |
| 網路負載 | 低 | 中 | 高 |
| 延遲 | 低（秒級） | 取決手動呼叫 | 取決輪詢間隔 |
| 適用情境 | 需要「立刻知道」的通知，如付款、訊息、新訂單 | 報表查詢、批量同步 | 舊系統或無法改造的場景 |
優點：即時、省流量、維護簡單
缺點：端點必須公開、無認證易被濫發、錯過事件需補償機制
Webhook 的應用場景有哪些？
- 電商：付款成功→倉儲出貨
- 行銷自動化：表單送出→CRM 建客戶資料
- 客服：使用者留言→Slack/LINE 群組即時提示
- DevOps：Git push→CI/CD Pipeline
- IoT：感測器異常→簡訊警報
- 教育：學生完成測驗→寄成績單 PDF
如何設置與使用 Webhook？
- 找出來源支援
多數 SaaS（Stripe、LINE Bot、WordPress、Shopify）已內建 Webhook 設定頁。 - 建立接收端
- 傳統伺服器：Nginx + PHP / Node.js
- 免後端：Zapier‧Make.com‧n8n
- 驗證簽章
以 Node.js 為例：crypto.createHmac('sha256', secret).update(payload).digest('hex') - 回應 200
若處理成功，回傳 200 OK；否則來源會重送（通常最多 3～5 次）。 - 監看 & 除錯
工具：RequestBin、Webhook.site（近 2025/4 剛更新自訂網域支援）
掌握以下幾個基礎概念和技術，就能幫助你成功操作 Webhook 的功能
1. HTTP 基礎
- 什麼是 HTTP（超文本傳輸協定）：Webhooks 通常是基於 HTTP 協議進行通信的。你需要了解 HTTP 請求的基本結構，例如 GET、POST、PUT 和 DELETE 等請求方法，以及如何構造這些請求。
- URL 和端點概念：Webhook 通常是發送 HTTP 請求到特定的 URL。理解如何設定和管理 API 的端點（Endpoint）是很重要的。
2. API 基礎
- 什麼是 API（應用程式介面）：Webhook 常與 API 配合使用，當事件發生時，Webhook 會觸發 API 請求。你需要理解 API 的工作原理，特別是如何通過 API 訪問和操作數據。
- JSON 和 XML 格式：許多 Webhook 請求的數據格式是 JSON 或 XML，因此了解如何解析和生成這些格式的數據是必要的。
3. 伺服器與回應處理
- 伺服器基本知識：要接收 Webhook 事件，你的伺服器需要能夠處理 HTTP 請求。了解如何設定伺服器來接收 Webhook 請求並做出相應的回應是基本要求。
- 處理請求和回應：理解如何在伺服器端處理來自 Webhook 的請求並根據需要回應對方系統。通常這會涉及到 POST 請求，並且要能處理 JSON 或其他格式的數據。
4. 安全性設定
- 簽名和驗證：許多 Webhook 服務提供簽名機制來確保請求是從可信來源發出的。了解如何使用 Webhook 簽名來驗證請求的合法性是重要的。
- 防止重放攻擊：學習如何避免 Webhook 請求被篡改或重複提交。這通常包括使用 時間戳記 和 隨機數據 來防止重放攻擊。
5. 程式語言基礎
- 程式語言（如 Python、PHP、JavaScript）：操作 Webhook 常涉及編程，特別是設置伺服器端接收和處理請求。學會如何使用 Python、Node.js 或 PHP 等語言來編寫 Webhook 接收端的程式碼。
- 框架與庫：有些語言或框架（如 Flask、Express）會提供簡單的方式來處理 HTTP 請求，學會使用這些框架可以使開發變得更加簡單。
6. 測試與調試
- 測試工具（如 Postman）：學會如何使用測試工具來模擬 Webhook 請求，這樣你可以測試自己的伺服器是否正確接收並處理這些請求。
- 日誌記錄和錯誤處理：調試 Webhook 時，日誌記錄至關重要。了解如何設置伺服器日誌，捕捉錯誤並做出相應處理，能夠幫助你排查問題。
7. Webhooks 平台和服務
- 第三方 Webhook 服務：了解常用的 Webhook 平台（如 GitHub、Stripe、PayPal、Slack 等）以及如何設定這些平台上的 Webhook。
- Webhook 配置：學會如何在這些平台上創建和管理 Webhook，並指定需要通知的 URL（即你的伺服器端點）。
實作步驟概述：
- 創建 Webhook 端點：設定伺服器來接收 Webhook 請求。
- 設定 Webhook 來源：在 Webhook 支援的服務中配置請求發送的 URL。
- 處理請求：根據 Webhook 發送的數據，執行相應的操作（如更新數據、觸發行為等）。
- 安全驗證：加入驗證機制確保請求是來自可信的來源。
- 測試與調試：使用測試工具來模擬和驗證 Webhook 的行為。
掌握這些基礎概念後，你就能夠順利設置和操作 Webhook，並在各種應用中進行自動化處理。
Webhook 適用人群與購買/替代建議
誰最適合？
| 角色 | 迫切痛點 | Webhook 能做什麼 |
|---|---|---|
| 開發者 | 需要 CI/CD、自動測試 | Push 一次，伺服器自動建置 |
| 行銷人員 | 想即時追蹤表單 | 送出表單即寫入 CRM |
| 企業主 | 想縮短訂單到出貨流程 | 付款→倉儲→物流同步 |
替代方案
- Polling API：若供應商不支援 Webhook，只能定時抓取；適合非即時需求。
- Message Queue（RabbitMQ、Kafka）：大量事件且需確保順序、可追溯。
- Server‑Sent Events / WebSocket：需要雙向長連線的互動式應用。
安全小提醒
因為這些請求等於「敲門」直接給你資料，所以接收方要驗證來源、檢查簽名或使用密鑰，避免有人冒充發送假訊息，也可以透過 IP 白名單或加密連線來加強保護
FAQ常見問題
最後小總結
Webhook 就像網路上的員工幫你跑腿，事件一響就把資料推送到指定網址，秒級完成庫存同步、發票開立到 LINE 通知，省去輪詢的流量與延遲。只要熟悉 HTTP 請求、驗簽安全與伺服器回應，配合 ngrok、Make.com 就能快速上線，把訂單、行銷或 CI/CD 的繁瑣流程通通自動化，讓團隊專注真正能賺錢的事。
