用 webhook.site 调试 UnifyPort webhook

它到底做什么

打开 webhook.site 的瞬间就给你一个临时 HTTPS URL。任何打到这个 URL 的请求——从一行 curl 命令到真实生产 webhook——都会出现在 dashboard 里，完整看到 headers、原始 body、query string 和时序。无需注册、无需安装。免费版 URL 保留一周，付费版更长。

UnifyPort 集成里什么时候用它

说实话：每当你怀疑问题可能不在你那边、在我们这边时。具体来说有三个常见时刻：

• 1. 首次连通性确认。在真实 handler 写好之前，把设备的 webhook endpoint 指到一个 webhook.site URL，触发一条测试消息。事件能到，就说明连通性、账号绑定、provider 会话三个环节全都健康。
• 2. 对比丢失的事件。当你的 handler 没收到本该收到的事件（比如 Telegram message.received），临时多加一个 target 指向 webhook.site。如果那边收到、你这边没收到，bug 在你代码里；两边都没收到，提工单时附上 delivery id。
• 3. 看一眼那些你忘了的字段。Dashboard 显示我们投递的完整规范化 JSON——包括 data.attendees、data.conversation.title 这些不是每个事件都出现的可选字段。比翻文档快。

认出 X-Device-Signature

当 target 配置了签名密钥时，每次投递都会带三个自定义 header：

三个都会出现在 webhook.site 的 Headers 面板里。如果还不想写代码就要验证签名是否对，拿 timestamp 和原始 body 跑一遍我们的 CyberChef 详解，用你的 secret 算出来的 hex 应该跟 header 一字不差地对上。

什么时候不要用它

任何贴近生产流量的场景：真实客户消息、你正在用的签名密钥、不该留在别人服务器上的 PII。webhook.site 的 URL 是可猜的、公开的——假定你贴上去的东西任何人都能读到。需要长期跑、对真账号做调试时，换 smee.io 或自托管 bin。

我们也喜欢的替代品

• Pipedream RequestBin——需要观察几个小时流量时更合适。
• smee.io——转发到 localhost 而不仅仅是捕获，更适合本地开发循环。
• ngrok——完整本地 tunnel，127.0.0.1:4040 内置 inspector。我们真开发时开得最多的就是这个。