| name | webhook-async |
| description | 设计 Webhook 和异步 API 时使用。适用于事件订阅、长任务、第三方集成。优先使用 HMAC 签名 + event_id 去重 + 重试策略 + 异步任务状态查询。 |
Webhook 和异步 API
参考来源：Stripe Webhooks、SVIX Webhook Guide
适用场景
- 事件驱动通知（订单状态变化、支付成功）
- 第三方集成（GitHub Actions、CI/CD）
- 长时间任务（导出报表、视频转码）
- 异步处理（消息队列）
核心原则
1. 不可信网络
- 必须签名验证
- 必须防重放
2. At-least-once 投递
- 接收方必须幂等
- 提供 event_id 去重
3. 异步状态可查询
- 不能"提交完就消失"
- 提供任务 ID + 查询接口
4. 失败可重试
- 重试策略明确
- 失败有上限
Webhook 设计
事件 Payload 结构
{
"id": "evt_abc123", ← 事件 ID（去重用）
"type": "order.paid", ← 事件类型
"created_at": "2026-01-15T10:30:00Z", ← 触发时间
"version": "2026-01-01", ← API 版本（用于兼容）
"data": {
"order_id": "ord_xyz789",
"amount": 9999,
"currency": "CNY",
"user_id": "usr_001"
},
"previous": { ← 可选：变更前的值
"status": "pending"
},
"metadata": {
"ip": "1.2.3.4",
"user_agent": "..."
}
}
事件命名规范
[资源].[动作]
✅ 好的：
order.created
order.paid
order.cancelled
payment.failed
user.signed_up
subscription.expired
❌ 差的：
newOrder（驼峰）
order_paid_event（冗余 _event）
notification_1（无语义）
HMAC 签名（必备）
请求 Header：
X-Webhook-Signature: t=1611331200,v1=abc123def456
X-Webhook-Timestamp: 1611331200
签名生成（服务端）：
signed_payload = f"{timestamp}.{request_body}"
signature = HMAC-SHA256(webhook_secret, signed_payload)
接收方验证：
1. 检查 timestamp（防重放，5 分钟内）
2. 用相同算法计算签名
3. 与 Header 中的签名对比
4. 不一致 → 拒绝
代码示例（Python）：
import hmac, hashlib
def verify(payload, signature_header, secret):
timestamp = parse_timestamp(signature_header)
if abs(time.time() - timestamp) > 300: # 5 分钟
return False
expected = hmac.new(
secret.encode(),
f"{timestamp}.{payload}".encode(),
hashlib.sha256
).hexdigest()
return hmac.compare_digest(expected, signature_from_header)
重试策略
失败定义：
- 接收方返回非 2xx
- 超时（通常 10s）
- 网络错误
重试时间表（指数退避 + 抖动）：
第 1 次失败：1 分钟后重试
第 2 次失败：5 分钟后
第 3 次失败：30 分钟后
第 4 次失败：2 小时后
第 5 次失败：12 小时后
第 6 次失败：24 小时后
最多重试：N 次（如 10 次）
接收方建议：
- 收到立即返回 200（哪怕处理失败）
- 把处理推到队列
- 处理失败由接收方自己重试
为什么？
发送方按 200 判定成功
如果接收方阻塞处理，会被发送方判定失败而重发
接收方实现要点
1. 立即返回 200
不要等业务处理完
防止超时被重发
2. 验证签名
不验证 = 任何人都能伪造事件
3. 检查 event_id 去重
存数据库或 Redis
防止 at-least-once 导致的重复处理
4. 处理失败时重新入队
不依赖发送方重试
5. 处理超时控制
不要长任务阻塞 webhook 端点
端点设计
为接收方提供 Webhook 端点：
POST https://customer.com/webhooks/example
接收方注册端点：
POST /webhook-endpoints
{
"url": "https://customer.com/webhooks/example",
"events": ["order.paid", "order.cancelled"],
"secret": "whsec_xxx" ← 用于签名
}
测试 Webhook：
POST /webhook-endpoints/{id}/test
触发一个测试事件
异步 API 设计
长任务模式
1. 提交任务（立即返回）
POST /reports/export
Body: { "type": "user_list", "format": "csv" }
→ HTTP 202 Accepted
{
"task_id": "task_abc123",
"status": "pending",
"status_url": "/tasks/task_abc123"
}
2. 查询状态
GET /tasks/task_abc123
→ {
"id": "task_abc123",
"status": "running",
"progress": 60,
"estimated_completion": "2026-01-15T10:35:00Z"
}
3. 完成
GET /tasks/task_abc123
→ {
"id": "task_abc123",
"status": "completed",
"result_url": "/files/report_xyz.csv",
"completed_at": "2026-01-15T10:35:30Z"
}
4. 失败
GET /tasks/task_abc123
→ {
"id": "task_abc123",
"status": "failed",
"error": {
"code": "data_too_large",
"message": "Export exceeds 1M rows"
}
}
任务状态机
pending → running → completed
→ failed
→ cancelled
状态获取方式
方式 1：轮询（Polling）
客户端定时查询 status_url
简单但低效
适合：短任务（< 1 分钟）
方式 2：Webhook（推送）
完成后推送给客户端
高效但需要接收方有 webhook
适合：长任务
方式 3：Server-Sent Events（SSE）
服务端持续推送进度
适合：实时进度（如 AI 生成）
方式 4：WebSocket
双向通信
适合：实时交互
输出格式
## Webhook 设计：[业务模块]
### 事件清单
| 事件 | 触发条件 | Payload | 用途 |
|------|---------|---------|------|
| order.created | 订单创建 | { order_id, ... } | 通知接入方 |
| order.paid | 订单支付完成 | { order_id, amount } | 触发发货 |
| order.cancelled | 订单取消 | { order_id, reason } | 解锁库存 |
### 签名规范
- 算法：HMAC-SHA256
- Header：X-Webhook-Signature
- Secret：注册端点时生成
### 重试策略
- 失败：返回非 2xx 或超时（10s）
- 重试时间表：1m / 5m / 30m / 2h / 12h / 24h
- 最大重试：10 次
### 端点管理
- POST /webhook-endpoints 注册
- GET /webhook-endpoints 列出
- DELETE /webhook-endpoints/{id} 删除
- POST /webhook-endpoints/{id}/test 测试
## 异步 API 设计：[业务模块]
### 长任务清单
| 接口 | 任务类型 | 预期耗时 | 状态查询 |
|------|---------|---------|---------|
| POST /reports/export | 导出报表 | 1~10 分钟 | GET /tasks/{id} |
| POST /videos/transcode | 视频转码 | 10~60 分钟 | Webhook 通知 |
| POST /jobs/sync | 数据同步 | 1~30 分钟 | SSE 进度推送 |
### 任务状态机
pending → running → completed / failed / cancelled
### 状态查询响应
[标准响应格式见上方]
工作流程
1. 识别哪些场景需要 Webhook（事件通知）
2. 识别哪些场景需要异步（长任务）
3. 列事件清单 + 命名
4. 设计 Payload 结构
5. 设计签名机制
6. 设计重试策略
7. 设计任务状态查询
8. 提供测试方式
9. 输出 Webhook + 异步 API 文档
质量自检
□ 事件命名一致（resource.action）
□ 事件 Payload 包含 event_id（去重用）
□ Payload 包含 timestamp 和 version
□ HMAC 签名机制设计
□ Timestamp 防重放（5 分钟内）
□ 重试策略明确
□ 异步任务有 status_url
□ 任务状态机清晰
□ 任务失败有错误信息
□ 提供测试 / 调试方式
常见坑
- Webhook 没签名——任何人都能伪造事件
- 签名缺 timestamp——重放攻击风险
- 没有 event_id——接收方无法去重
- 接收方处理慢导致重发——应立即返回 200
- 重试无上限——失败的端点收到无限请求
- 异步任务无状态查询——客户端不知道好没好
- 任务失败无错误信息——调试困难
- Payload 不带版本——升级时接收方崩溃
配套模板
templates/webhook-async-template.md — 事件 Payload + 签名规范 + 异步任务设计模板
与其他 skill 的协作
上游：
resource-modeling → 资源的状态变更触发事件
平行：
auth-permission → Webhook 端点鉴权
idempotency-retry → 重试机制
error-handling → 错误码
下游：
openapi-mock → 写入 OpenAPI（含 Webhook schema）
转交后端 → 实现签名 + 重试 + 队列
转交安全 → 评审签名机制
