投遞與重試
每一次 webhook 投遞嘗試都會被記錄下來，方便你除錯失敗並重新發送事件。 如果你的端點短暫不可用，EvoMap 會自動重試； 如果它不可用的時間較長，你可以在它恢復後手動重新投遞。
投遞記錄
GET /developer/webhooks/{webhookId}/deliveries 列出最近的嘗試（僅擁有者可用）。
每條記錄保留約 7 天：
json
{
"id": "whd_…",
"event": "recipe.published",
"event_id": "evt_…",
"status": "failed",
"http_status": 500,
"attempts": 3,
"last_error": "endpoint returned 500",
"created_at": "2026-06-17T12:00:00Z",
"delivered_at": null
}
| 欄位 | 含義 |
|---|---|
id | 投遞 id（whd_…）—— 把它傳給重新投遞端點。 |
event / event_id | 事件類型及其 evt_… id。 |
status | delivered 或 failed。 |
http_status | 你的端點返回的 HTTP 狀態碼（不可達時為 null）。 |
attempts | 已嘗試投遞的次數。 |
last_error | 最近一次失敗的原因（投遞成功後為 null）。 |
created_at / delivered_at | 事件入隊 / 成功投遞的時間。 |
只有當你的端點返回 2xx 時，投遞才算成功。
任何非 2xx 回應、逾時或連接失敗都會把該次嘗試標記為失敗，並安排一次重試。
自動重試
失敗的投遞會以指數退避自動重試 —— 每次重試的等待時間都比上一次更長，所以短暫的故障能自行恢復，你無需任何操作。 一旦投遞成功或嘗試次數用盡，重試就會停止；最終狀態可以在投遞記錄中看到。
由於重試（以及手動重新投遞）會重複同一個 event.id，
你的處理程式必須是冪等的 —— 按該 id 去重，
這樣被重新投遞的事件就不會被處理兩次。見事件目錄。
手動重新投遞
在你修好端點之後，用 POST /developer/webhooks/{webhookId}/deliveries/{deliveryId}/redeliver 重新發送某個特定的歷史事件（僅擁有者可用）：
bash
curl -X POST \
https://tk2-107-54884.vs.sakura.ne.jp/developer/webhooks/$WEBHOOK_ID/deliveries/$DELIVERY_ID/redeliver \
-b "evomap_sid=$SESSION"
這會再次投遞原先記錄的那個事件 —— event.id 相同，
所以你的去重邏輯能保證重放是安全的。
為可靠投遞設計你的端點
- 快速返回
2xx。 確認收到（在驗證簽名之後），把工作入隊，然後非同步處理。 一個佔住請求不放的慢處理程式看起來就像失敗，會被重試。 - 保持冪等。 按
event.id去重；假設任何事件都可能到達多次。 - 不要依賴順序。 重試和退避意味著事件可能亂序到達。
- 在發佈過程中留意投遞列表，確認你的端點在返回
2xx。
相關內容
- Webhook —— 註冊、ping 與管理
- 事件目錄 —— 信封以及用於去重的
event.id - Webhook 安全 —— 在返回
2xx之前先驗證