用 Pipedream RequestBin 观察 UnifyPort webhook 事件流

它做什么

RequestBin 给你一个持久的 URL，把每条请求都记进一份可滚动的历史里——headers、raw body、query string、时序——而且会留着，方便你几个小时后再回来看。一个 replay 按钮可以重发任何一条已捕获的请求，这正是它不只是个被动查看器的原因。

什么时候用它

• 观察一连串事件。 一条消息可能先扇出 message.received，再跟着好几条 message.status.updated。RequestBin 把它们按顺序铺开，你就能确认整串事件都到齐了。
• 跨越好几分钟的鉴权流程。 二维码和配对流程会先后发出 account.auth.required、account.auth.succeeded、account.started，间隔几秒到几分钟。持久的收集箱能把它们全接住，你不用一直盯着终端。
• 边迭代边 replay。 捕获一次，之后改代码时把同一条投递重放到你的 handler——比每次都去哄渠道再发一遍同样的事件快得多。

查看一条 UnifyPort 投递

每条投递都带着标准的签名 headers：

……以及归一化后的事件信封——跨渠道都是同一个结构，所以你只需照它写一次 handler：

什么时候别用它

• 生产或含 PII 的流量。 RequestBin URL 公开且可被猜到——拿到链接的人都能读到每条捕获的请求。只留给一次性的测试事件。
• 要转发到 localhost。 RequestBin 只捕获，不会转发到你的机器。要转发就用 smee.io 或 ngrok。

我们也喜欢的同类工具

• webhook.site——一次性确认"有没有东西进来"更快。
• smee.io——会转发到 localhost，而不只是捕获。
• ngrok——完整的本地隧道，自带 127.0.0.1:4040 inspector。

常见问题

Pipedream RequestBin 的请求能留多久？

够你在一段会话里看着流量累积——比快速确认一下需要的时间长得多。具体保留时长取决于你的 Pipedream 套餐，所以把捕获的请求当测试数据看，别当成归档。

能把捕获的请求 replay 到我本地的 handler 吗？

RequestBin 重放到原来的目标。想把投递送到 localhost，用 smee.io 转发，或用 ngrok 开隧道，再在那边 replay。

它和 webhook.site 有什么区别？

两者都捕获并展示请求。webhook.site 在一次性确认"到没到"时最快；RequestBin 更适合你想要一份持久、可滚动、跨越一段时间的多条投递历史的时候。