AO2 FIELD GUIDE · N113 · 行銷自動化與工具整合
Webhook 網站詢問流程把事件發送、來源驗證、接收確認與後續處理分開。用去識別事件示例和狀態表，說明 HTTP 成功、重送、去重與人工接手，不把通知當成交或處理完成。
網站有人送出需求，另一個系統要如何知道？Webhook 可以在事件發生時把通知送到指定接收點，但傳過去只是開始。還要確認來源、資料是否可用、同一件事是否處理過，以及後續失敗由誰接手。
Webhook 網站詢問，先把通知與工作分開
Webhook 是某個事件發生後，由來源系統向指定網址送出請求，讓接收方開始處理的機制。以網站詢問為例，來源可能在成功接收表單後通知整合服務，再由整合服務安排任務或寫入 CRM。各產品支援的事件、格式與認證方式不同，需要以當前官方文件核對。
通知已送達、資料已接收與商機已建立，是三種不同狀態。流程圖先把它們分開，才能知道報錯在哪一段。沒有 Webhook 也可能用排程查詢或其他方式整合；先看事件時效、工具能力和維護責任，不把這個名詞當成一定比較先進的方案。
白話例子：門鈴響了，不代表包裹已完成入庫
假想倉庫收到送貨員按門鈴。門鈴通知有人到達，門口人員還得核對送件身分、包裹標籤，留下收件紀錄，再交給庫房處理。若對講機說「收到」，不能推論庫房已放到正確貨架；送貨員沒聽見回應再按一次，也不代表多了一個包裹。
門鈴對應事件通知，身分核對是來源驗證，收件紀錄是可追查的接收狀態，入庫才是後續工作。這是假想流程示例，不是實際系統紀錄。Webhook 的請求與回應還有具體協定和安全條件，比喻只能幫助理解分工，不能取代供應商文件、權限設定與測試。
先訂事件契約，別把整份表單直接往外倒
契約至少包含事件類型、事件識別、提交識別、發生時間、資料結構版本，以及接收方實際需要的業務欄位。事件 ID 用來辨認通知，提交 ID 用來辨認一次詢問，不能因為看起來像編號就任意互換。資料不足或版本未知時，應明確拒絕、隔離或待人工處理，不猜測必要值。
以下示例只用測試識別、需求類別與產品代稱，不含聯絡資料。真正要交換哪些欄位，應按用途、權限與保存範圍決定；秘密值不放網址或公開文件。接收網址能被呼叫，不等於只有可信來源會呼叫它，因此還需要核對各平台提供的驗證與防重放方法。
| 階段 | 可以說什麼 | 還不能說什麼 |
|---|---|---|
| 來源發出 | 產生一筆事件投遞 | 接收方已拿到 |
| 來源與格式通過 | 可信且符合已知契約 | CRM 已完成建立 |
| 可靠接收 | 事件有可追查紀錄或可靠排程 | 所有後續工作都成功 |
| 業務處理完成 | 對應任務或商機已核對 | 已成為合格需求或成交 |
去識別的事件示例
以下為假想資料格式，不是可直接連到正式系統的設定。
{
"event_id": "evt_demo_001",
"event_type": "inquiry.received",
"submission_id": "sub_demo_001",
"occurred_at": "2026-10-24T09:00:00+08:00",
"schema_version": "1",
"data": {
"topic": "integration",
"product_ref": "demo-sensor-a"
}
}來源驗證、可靠接收與業務處理依序完成
例如 GitHub 的 Webhook 文件要求用秘密值驗證請求簽章，並說明應使用原始內容及適當的安全比較方式；這是該平台的具體做法，不能把標頭名稱直接套用到每家工具。無法通過來源或格式驗證的資料，不應先寫入業務系統，再寄望事後清理。
有效請求可先留下可持續追查的收件紀錄或交給可靠佇列，再依平台要求回應，後續處理另記狀態。不能只是放進會隨程序結束消失的記憶體，就把工作當成安全接收。回應時限依供應商不同；GitHub 文件的十秒要求不是所有 Webhook 的通用標準。
重送、對帳與人工接手要在上線前走過
接收方已完成工作，但回應在途中遺失時，來源可能把通知判為失敗。同一事件再次抵達，應查原有處理狀態，而不是再建立一次商機；真正新的詢問則不應因內容相似就被刪掉。具體去重規則可接著看既有的重複提交指南，本篇先把事件和業務工作的邊界說清楚。
HTTP 成功回應，只能按你們約定的階段解讀。保留事件 ID、提交 ID、每次投遞、接收與業務結果，才能對帳。各平台的失敗重送、保留期限和人工重送方式不同，不要假設會永遠自動補送。測試逾時、格式不合、重送及後端失敗，並指定告警與接手人，才算完整交接。
| 情境 | 預期行為 | 驗收證據 |
|---|---|---|
| 同一事件再送 | 不重複產生相同副作用 | 同事件的投遞與既有處理狀態 |
| 新提交內容相似 | 依提交與事件規則辨認 | 沒有把新需求誤刪 |
| 後端暫時失敗 | 保留待處理狀態並依規則接手 | 重試、告警及責任人 |
| 來源或版本不明 | 不猜資料、不先執行業務 | 拒絕或隔離原因及安全紀錄 |
常見問題
Webhook 和 API 有什麼不同？
Webhook 通常是來源在事件發生時主動呼叫接收網址；一般主動查詢則由使用方發出請求取得資料。兩者都可能使用 HTTP，也可以在同一套流程配合。先看誰發起、事件何時產生和如何確認結果，不要把名稱差異直接當成可靠性或即時性的保證。
工具說會重試，還需要自己留紀錄嗎？
需要。重試次數、期限、觸發條件和重送 ID 的規則各不相同，也可能需要人工補送。接收方應保存足以核對同一事件及處理結果的紀錄，避免再次產生副作用；再用實際失敗情境驗證告警和接手。不要把供應商會重試當成永不遺失或剛好處理一次的保證。
同一事件晚到或亂序送達，會把商機狀態改回舊版嗎？
如果無條件覆寫，確實可能退回舊狀態。應檢查事件識別、版本或時序，以及允許的狀態轉換；過期或重複事件保留紀錄並依規則處理，不直接覆蓋最新資料。
例如已接手的詢問，不該因晚到的「新建」通知變回未分派。驗收需包含重複、延遲、亂序與補查，不只測通知能到達。
白話總結：把門鈴、收件與入庫分開驗收
Webhook 先通知事件發生；驗證、可靠接收和業務完成仍各有責任。把每段狀態留下，才知道問題停在哪裡。
- 訂契約：固定事件、提交、版本及必要欄位，不外送多餘資料。
- 驗接收：確認來源與格式，留下可靠紀錄，再按約定回應。
- 走例外：測重送、逾時及後端失敗，核對去重、對帳和人工接手。
完成條件：每筆事件能追到接收與業務結果，重送不重複做事，新需求不被誤刪。
來源與方法範圍
資料查核：2026 年 10 月 24 日。來源支持文中對應的準則與平台說明；工作表、判斷步驟及已標示的假想情境由 AO2 整理，實際使用時依產品資料與現行設定核對。
