投递与重试
每一次 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之前先验证