Webhook 與輪詢——哪種方式適合你？

大家好，我是 Chae-won。

系統之間交換資料有兩種主要方式：Webhook 和輪詢（polling）。名稱聽起來很技術，但概念其實很簡單。

在之前的文章中，我介紹了 Webhook。今天來跟輪詢做個比較，幫你判斷哪種方式適合你的情況。

再用一次配送的比喻

輪詢就像每小時打電話給物流司機問：「我的包裹到了嗎？」即使還沒到，你也一直打。直到終於聽到「到了」才停下來。

Webhook就像家裡裝了門鈴。包裹到了，司機按門鈴。你不用主動問——系統自動通知你。

用技術術語來說：

• 輪詢：定期詢問「有新資料嗎？」（拉取）
• Webhook：有新資料時自動通知（推送）

比較表

	輪詢	Webhook
運作方式	定期請求	事件驅動通知
即時性	低（取決於間隔時間）	高（幾乎即時）
效率	低（很多空回應）	高（有需要才觸發）
實作難度	相對容易	需要接收伺服器
資料遺漏	間隔之間可能遺漏	失敗可重試
伺服器負載	高（持續請求）	低（僅在事件發生時）
成本	與請求次數成正比	與事件次數成正比
注意事項	留意 API 速率限制	可能有重複、不保證順序

使用 Webhook 需要知道的事

Webhook 很高效，但有幾個特性值得了解：

• 接收端速率限制 — 你的伺服器可能有每秒請求上限。如果資料大量湧入，部分可能被拒絕。上線前請確認雙方的處理限制
• 重複傳送 — 如果網路問題讓傳送方以為傳送失敗，它可能會重試，導致同一筆資料傳送兩次。對於重要資料，使用唯一識別碼如 order_id 來過濾重複
• 不保證順序 — Webhook 不保證事件按順序到達。「訂單已更新」的通知可能比「訂單已建立」先到。使用時間戳記來判斷先後順序
• 回應時間 — Webhook 傳送方通常預期在 5-10 秒內收到回應。如果需要大量處理，先快速回覆確認，再非同步處理

這些特性正是為什麼，如同下面要討論的，許多實際部署會將 Webhook 與輪詢搭配使用。

什麼時候輪詢比較適合

輪詢不是壞方法。在以下情況其實更好用：

• 對方不支援 Webhook — 有些系統還是不提供 Webhook 功能。這種情況下輪詢是唯一選擇
• 批次拉取歷史資料 — 「取得過去一個月的所有訂單」就是輪詢（API 查詢）的使用場景
• 即時性不重要 — 如果每天同步一次就夠了，輪詢完全可以

什麼時候 Webhook 比較適合

對大多數商業場景來說，Webhook 是更好的選擇：

• 你需要即時通知 — 訂單、付款、預約等需要立即處理的事
• 你想降低成本 — 不會浪費在「有新東西嗎？」的空請求上
• 你在建立自動化流程 — 「訂單進來 → LINE 通知 → 自動記錄」的工作流
• 你在整合多個資料來源 — 每個來源推送資料給你；你在一個地方管理

Webhook 的一個門檻：接收伺服器

使用 Webhook 最大的障礙是你需要一台伺服器來接收。

輪詢是你主動發出請求——一個簡單的腳本就行。但 Webhook 是對方傳送給你，所以你需要一個可以接收的網址。通常這意味著要架設或開發一台伺服器。

3Min API 正是解決這個問題的。它為你建立 Webhook 接收網址——不需要伺服器。幾個點擊，你的 Webhook 端點就準備好了。

實務上的組合：Webhook + 輪詢

在實務中，許多系統兩者一起使用：

• 即時資料透過 Webhook
• 歷史同步和補漏透過輪詢（API 查詢）

例如，透過 Webhook 即時接收電商訂單，同時每天跑一次 API 查詢確認「有沒有遺漏的？」

3Min API 也支援這種組合。你透過 Webhook 接收資料，需要時隨時透過儀表板或 API 查詢已儲存的資料。

總結

• 需要快速、自動化的資料接收？→ Webhook
• 需要歷史資料或對方不支援 Webhook？→ 輪詢
• 最可靠的方式？→ Webhook + 輪詢搭配使用

如果你不確定哪種適合，先從 Webhook 開始。它在大多數商業場景中更高效，也是自動化的基礎。