什麼是 Webhook？非工程師也能懂的簡單說明

大家好，我是 Chae-won。

在介紹 3Min API 時，我最常被問到的問題就是「什麼是 Webhook？」對開發人員來說是理所當然的概念，但對非技術背景的人來說，可能是一個完全陌生的詞。

今天讓我用最簡單的比喻，來說明 Webhook 是什麼、為什麼重要，以及它是怎麼運作的。

開始之前先說一件事。其實Webhook 和 API 在技術上是完全一樣的工具。窗口、訊息的形狀、認證方式都一樣，不同的只有「誰先打過去」這一點。我先打過去就叫 API，對方先打過來就叫 Webhook，只是換了個名字而已。所以「API 到底是什麼我都還沒弄清楚」的朋友，可以先去看一眼 yeonghyeon 寫的寫給非開發者店主的 API 入門指南再回來。如果您已經對 API 有感覺了，可以直接跳到下面的包裹比喻。

用包裹配送來理解 Webhook

想像你訂了一個包裹，有兩種方式可以確認配送狀態。

方法一：自己查
你打開物流追蹤 App，不斷按重新整理。早上、中午、晚上——即使什麼都沒變也一直查。在 IT 領域，這叫做輪詢（polling）。

方法二：收到通知
你設定推播通知：「狀態有變化時通知我。」你不用主動查——App 在狀態變化時自動通知你。這基本上就是Webhook 的運作方式。

更精確地說

Webhook 就是「當事件發生時，自動將資料傳送到指定的網址。」

舉例來說：

• 當網路商店有新訂單進來 → 訂單資料傳送到你的系統
• 當付款完成 → 付款資訊自動記錄到你的儀表板
• 當客戶提交問卷 → 回覆資料加入你的試算表

看出規律了嗎？「當 X 發生 → 執行 Y。」你不用去拿資料——資料會主動來找你。

為什麼 Webhook 很重要？

在商業中，資料需要快速流動。如果合作夥伴下了訂單，你三個小時後才手動查看，事情就會被遺漏。

有了 Webhook：

• 資料即時到達。訂單進來的那一刻你就知道
• 它是自動的。不需要任何人手動查看
• 它是高效的。只有在真正有事發生時資料才會流動——沒有浪費的流量

3Min API 中的 Webhook

以下是 Webhook 在 3Min API 中的運作方式。

當合作夥伴將資料傳送到你的 API 端點時，3Min API 會儲存資料，同時將其轉發到你指定的網址。例如，轉發到你的 CRM、LINE 群組，或你自己的內部系統。

設定很簡單。建立端點時，只要輸入「傳送到這個網址」就好了。每次資料到達時，都會自動轉發。

如果 Webhook 傳送失敗怎麼辦？3Min API 會自動重試——最多 3 次。如果仍然不行，嘗試會被記錄下來，你可以之後查看。

Webhook 與輪詢——哪個更好？

結論是：在大多數商業場景中，Webhook 好得多。

輪詢意味著不斷地問「有新東西嗎？」——即使什麼都沒有。它消耗伺服器資源、速度較慢，而且成本更高。

Webhook 意味著「有新東西時告訴我。」只在需要時觸發——效率高得多。

不過 Webhook 有一個門檻：你需要一個能接收 Webhook 的網址。通常這意味著你需要一台伺服器——而這正是 3Min API 幫你解決的。它不需要伺服器就能建立接收 Webhook 的端點。

Webhook 收不到資料時該檢查什麼

如果你已經設定了 Webhook 但資料沒有進來，不要慌。通常是以下原因之一：

• 網址正確嗎？ — 打字錯誤是最常見的原因。仔細檢查 https:// 和 http://。大多數服務要求 HTTPS
• 認證資訊正確嗎？ — 錯誤的 API 金鑰或認證標頭會導致 403 拒絕
• 接收端有速率限制嗎？ — 某些系統限制每秒或每分鐘的請求數量。超過限制意味著資料被拒絕
• 回應時間太慢嗎？ — Webhook 傳送方通常預期在 5-10 秒內收到回應。回應太慢可能被視為失敗
• 防火牆有阻擋嗎？ — 如果你在自己的伺服器上接收 Webhook，請檢查防火牆和 IP 白名單設定

當你使用 3Min API 作為接收端時，以上大部分問題都已經幫你處理好了——HTTPS、認證和伺服器可用性都由服務管理。但如果你有自己的系統在接收從 3Min API 轉發的 Webhook，請務必檢查上述項目。

總結

• Webhook 就是「事件發生時自動通知」
• 它就像物流追蹤 App 的推播通知
• 讓你即時、自動、高效地取得商業資料
• 即使沒有伺服器，也可以用 3Min API 接收 Webhook
• 收不到資料時，檢查網址、認證、速率限制、回應時間和防火牆

如果「Webhook」這個詞以前讓你覺得很難，希望現在感覺比較親切了。它的本質就是「自動送達」——就這麼簡單。