Webhook Tester

Webhook 测试器是一个临时公共地址，它会记录发送到它的每一个 HTTP 请求，让你看清 Webhook 发送方到底投递了什么。在下方创建一个钩子，你就会得到一个有效期 30 分钟的唯一 URL：把 Stripe、GitHub、支付服务商、监控服务或你自己的代码指向它，触发事件，每一次投递都会落在这里——方法、路径与查询参数、请求头、请求体和来源地址——供你在接上真正的处理器之前仔细检查。

最后更新:

本服务存储什么——以及它绝不做什么

创建一个钩子只会在 SysOSX 检查服务器上存储钩子 id、它的创建与过期时间，以及创建者的地址。每个被捕获的请求存储到达时间、方法、带查询字符串的路径、原样发送的请求头、最多 256 KB 的请求体（超出部分会被截断并标记），以及发送方地址。一个钩子最多保存 50 个请求；之后的投递会被拒绝，直到钩子过期。所有内容在钩子创建 30 分钟 后删除，或在你按下删除按钮时立即删除。接收器只负责接收：它从不抓取、跟随或重放任何内容——被捕获的请求不会触发任何出站调用。相邻的调试工具请看 HTTP 状态链追踪器，完整工作流程请读 无需管道工程，调试 Webhook。

为什么没有接收器时调试 Webhook 这么别扭

Webhook 是别人的服务器按他们的时间表、因你无法控制的事件——支付成功、推送落地、警报触发——来调用你的服务器。这种形态正是 Webhook 难以调试的原因。发送方无法访问你的笔记本电脑，所以本地开发需要隧道或公共预发布机器，才能看到一次真实投递；事件可能很难触发第二次，所以你确实得到的那一次投递最好被完整捕获；而当某些东西失败时，发送方的仪表板通常只显示你的端点返回的状态码，而不是它实际发送了什么。签名头在吗？请求体是文档承诺的 JSON 形状，还是表单编码？重试发送的是同一个事件 id 吗？如果你的处理器在记录日志之前就拒绝了请求——而签名和解析类 bug 恰恰主导着 Webhook 调试——这些问题仅凭处理器日志都无法回答。

临时接收器把管道工程从这个循环中去掉。你不必为了看清到达了什么就部署一个写了一半的处理器，而是创建一个接受一切、如实记录并展示给你的地址：按到达顺序和原始大小写呈现的请求头、在任何解析器有机会拒绝它之前的原始请求体、发送方有时藏参数的查询字符串，以及确切的方法——因为有些服务商用 POST 投递，有些用 PUT，还有少数用 GET 做健康检查。当屏幕上有一条真实捕获的投递时，你可以按照真相而不是文档来编写处理器，从实际负载构建测试夹具，并把失败的重试与原始投递并排对比。然后删除钩子，把服务商指向你的真实端点，再触发一次事件，看着你自己的处理器应答它。30 分钟是刻意设短的：足够完成一次调试会话，又短到不让一个被遗忘的、装满捕获负载的测试地址长期留在互联网上。

常见问题

一个钩子能活多久，能捕获多少？

钩子从创建起存活 30 分钟，然后钩子及它捕获的一切会被自动删除。它最多保存 50 个请求；超出后的投递会以 429 响应被拒绝，直到钩子过期。每个请求体最多存储 256 KB——更长的请求体会被截断，捕获记录会被标记为已截断，让你知道看到的不是全部。

谁能看到我的钩子捕获的内容？

任何拥有钩子 URL 的人。URL 中的 id 是唯一的凭证：它同时授权发送请求和读取捕获内容，之上没有账户也没有密码。这正是本工具即开即用的原因，也是你应该把 URL 当作密码的原因——不要公开张贴它，也不要把携带密钥或个人数据的生产流量指向这样一个共享查看器。

接收器会回复发送方、跟随链接或重放请求吗？

不会。接收器对每次被接受的投递只回复一个小的 200 JSON 确认，表示它已到达，除此之外什么都不做：它从不抓取负载中出现的 URL，从不跟随重定向，也不提供重放或转发。接收和检查就是全部服务，这能防止被捕获的负载变成出站流量。

我可以用它测试哪些发送方？

任何能向公共 URL 发送 HTTP 请求的东西：Stripe、GitHub、Shopify、支付和表单服务商、监控和 CI 服务、物联网设备，或你自己用 curl 写的代码。创建钩子，把 URL 粘贴到服务商的 Webhook 设置（或你的脚本）里，触发事件，几秒内就能看到投递到达这里。事后记得从服务商那里移除测试 URL，或把它指向你的真实处理器。