为什么「工作流优先」能更快排障
很多 Webhook 问题第一眼像厂商问题——Stripe 签名挂、GitHub 没投递、Shopify 静默失败——但底层往往是同一套流程：证明请求能到公网地址、看清它到底是什么、把它送进本地环境、再反复重放直到处理器通过。从工作流而不是从厂商入手，能更快判断坏在哪一层。下面四步就是这个流程；每步链到对应产品页，可立刻动手。当你撞上厂商特有的墙（签名、HMAC、事件类型边角），页面底部的各厂商 Hub 会接棒。
四步跑通 Webhook
从与你现状匹配的步骤进入即可，不必每次四步全走。
该用哪个工具
按你当下的处境选起点。
| 你的处境 | 更合适工具 | 原因 |
|---|---|---|
| 「不确定服务商有没有发任何东西」 | Request Bin | 提供公网端点捕获每次投递，先确认上游侧是否正常。 |
| 「能看到请求，但总觉得哪里不对」 | Request Viewer | 格式化展示 headers、body 与状态，比纯日志或控制台更快定位异常。 |
| 「需要真实流量打到本地服务」 | 本地转发 | 把线上捕获的流量送进本地处理器，无需部署或开端口。 |
| 「修完 bug，想用同一份 payload 再测一次」 | 重放 | 复用已捕获请求验证修复，无需在上游重复触发。 |
| 「签名验证一直失败」 | 调试器 + Viewer | 对照 raw body 与 headers，区分密钥、解析顺序或时间问题。 |
产品页
每个工作流步骤都对应可立刻操作的产品页。
按厂商深入
遇到厂商特有障碍时再切换这些 Hub。
- Stripe 指南
Stripe 本地测试、签名失败与重放。
- GitHub 指南
ping、签名验证与「没投递」排查。
- Shopify 指南
HMAC、订单事件与本地应用测试。
- Slack 指南
URL 验证、事件载荷与本地路由。
值得接着打开的文档
常见问题
必须按四步全部走一遍吗？
不必。从与你当前处境匹配的步骤切入：投递已确认就跳过 bin；只需要重放就直达重放。
这些工作流适用于任意 Webhook 发送方吗？
适用。捕获 → 检查 → 转发 → 重放与具体厂商无关，Stripe、GitHub、Shopify、Slack 及其他 HTTP 回调都同理。
request bin 和 webhook 调试器有什么区别？
bin 侧重捕获与展示；调试器在此基础上通常还提供转发、重放、签名相关能力与更持久的历史记录（以产品为准）。
什么时候从工作流指南切到「某厂商」专题？
当你遇到厂商特有问题时——例如 Stripe 签名、GitHub ping、Shopify HMAC。工作流解决通用分层；专题解决厂商差异。