先接受 Webhook 是至少一次傳遞
Webhook 經常被誤解為一次請求對應一次處理，但跨系統呼叫無法可靠地保證只傳一次。發送端可能已成功送達，卻因網路中斷而沒有收到回應；接收端也可能已完成資料寫入，卻在回傳成功狀態前逾時。此時發送端只能重試，因此工程上應把 Webhook 視為至少一次傳遞：事件可能沒有及時抵達，也可能抵達多次。
接收端收到請求後，不宜同步完成所有商業流程才回應。較穩健的作法是先驗證簽章與基本格式，將原始事件、事件識別碼、來源與接收時間可靠地寫入資料庫或佇列，再盡快回傳成功。後續的 ERP 更新、LINE 通知、CRM 寫入或 AI 分析交給背景工作處理。這能縮短發送端等待時間，但也代表「HTTP 成功」只表示事件已被接收，不代表所有下游動作都已完成。
- 成功接收：事件已持久化，可回傳 2xx，後續處理由內部工作機制負責。
- 暫時失敗：資料庫、佇列或必要服務暫時不可用，可回傳 5xx，讓發送端稍後重試。
- 請求錯誤：格式、簽章或必要欄位無效，應回傳合適的 4xx，避免無意義重送。
- 處理時間過長：不要讓連線持續等待；先安全收件，再以非同步方式執行。
重試策略要區分暫時與永久錯誤
重試不是固定間隔的無限迴圈。網路逾時、連線中斷、限流與短暫的服務不可用，通常值得重試；簽章錯誤、缺少必要欄位、已撤銷的權限或無法辨識的資源，則通常需要修正資料或設定。若把永久錯誤也持續重試，只會放大流量、塞滿佇列，並掩蓋真正需要人工處理的問題。
實務上可採用指數退避加隨機抖動，讓第一次重試較快發生，之後逐步拉長間隔，並用抖動避免大量事件同時重送。應設定最大嘗試次數或最長重試期限；超過後移入死信佇列或失敗事件表，而不是直接丟棄。若對方回傳 Retry-After，應在合理範圍內尊重該指示。逾時門檻也要依操作性質設定：連線逾時可較短，讀取逾時則應配合對方正常的處理時間。
發送端必須記錄每次嘗試的時間、回應碼、延遲與錯誤摘要，但避免將權杖、簽章密鑰或完整敏感資料寫入日誌。人工補送應沿用原事件識別碼與冪等規則，並保留操作者、原因與時間。否則維運人員按下「重送」時，可能繞過原有保護，造成第二筆訂單、重複通知或再次扣庫存。
冪等要保護業務結果，不只是 HTTP 請求
最理想的冪等鍵是由事件來源產生、全域穩定且每個業務事件唯一的 event_id。若來源沒有提供，可由接收端根據來源系統、事件類型與來源物件版本組成鍵；以整份 JSON 雜湊作為替代方案時，必須先做欄位排序與格式正規化，並排除簽章、傳送時間等每次可能變動的欄位。單靠時間戳或使用者識別碼通常不夠，因為同一時間可能有多個合法事件，而同一事件也可能被重新包裝。
接收事件時，應在資料庫建立唯一約束，例如來源加事件識別碼，並在同一交易中完成「登記事件」與「建立待處理工作」。不要只做先查詢、再插入，因為兩個並行請求可能同時查到不存在，接著各自執行一次。唯一索引、條件式寫入或原子 upsert 才能封住這個競爭條件。事件紀錄還應區分 received、processing、succeeded、failed 等狀態，讓重複請求可以回傳既有結果，或安全地等待原工作完成。
真正困難的是跨系統副作用。資料庫交易無法回滾已寄出的訊息或已送達第三方的 API 呼叫，因此每個下游動作也需要穩定的冪等鍵。可使用 inbox 模式避免重複消費，使用 outbox 模式在業務資料提交後可靠地發出下一個事件。若第三方不支援冪等鍵，應在本地保存外部操作的意圖與結果，透過狀態機控制重送，並針對結果未知的逾時先查詢對方狀態，而不是立即再執行一次。
順序、重播與可觀測性決定維運品質
冪等只能防止同一事件重複執行，不能解決事件順序錯置。若「訂單已取消」先於較舊的「訂單已更新」抵達，單純依接收順序處理可能讓狀態倒退。對有順序需求的資料，應帶入來源版本、遞增序號或事件發生時間，並在更新時比較目前版本。無法保證全域順序時，至少應保證同一業務實體依序處理，或把事件設計成包含足以重建當前狀態的資料。
維運介面至少要能依 event_id、來源物件與時間範圍查詢，看到目前狀態、嘗試次數、最後錯誤及下一次重試時間。告警應關注失敗事件累積、處理延遲、死信數量與特定回應碼的異常，而不只是單次請求失敗。重播工具則應支援權限控管、稽核紀錄、批次上限與預演，避免一次補送造成下游流量尖峰。
最後要用故障情境驗證設計：在寫入後故意中斷回應、同時送入相同事件、讓下游逾時但實際完成、交換事件順序，再確認業務結果仍然只有一份且可恢復。Webhook 的可靠性不是某個重試參數，而是接收、持久化、冪等、非同步處理與營運工具共同形成的系統能力。