物流 Webhook：不是留个 URL，是签收、重试与幂等的运输层
订单、轨迹、库存、费用等事件通过 Webhook 推给客户或内部系统。签名校验、失败重试、死信队列与事件目录要可运营，避免「推过了」无法举证。
对接会议上最容易被随口答应的词是 Webhook。上线后对方说没收到，你说发了——两边日志对不上，关系先裂。投递层要像承运商一样可追踪。
一条合格推送的标配
- HTTPS + 签名（如 HMAC）与时间戳防重放
- 明确 eventType 与版本
- 指数退避重试与最大次数
- 投递日志：请求、响应码、耗时、attempt
- 死信可查询、可按单重放
事件目录比「全能回调」重要
先公开一小撮稳定事件：出库、首扫、签收、费用确认。别一上来推内部草稿状态。快递飞做开放回调时，会把「可订阅事件清单」写进接口说明，和轮询 API 并存，而不是互相替代的口号。
常见问题
和消息订阅中心有何关系？
订阅决定「谁关心哪些事件」；Webhook 是投递通道之一（还可邮件/站内信）。事件模型应共用，通道可插拔。
如何防重复处理？
每个投递带 eventId；接收方按 eventId 幂等。发送方重试不换新 Id，换新的是 attempt 序号。
首期验收？
签约事件目录、签名验证样例、故意 500 触发重试、超过次数进死信可人工重放、关闭订阅立即停推。
所属专题
列表筛选「直邮与一单到底」 · 列表筛选「尾程与打单」 · 列表筛选「对接与运营」 · 列表筛选「交付与选型」