用 Pipedream RequestBin 觀察 UnifyPort webhook 事件流

它做什麼

RequestBin 給你一個持久的 URL，把每條請求都記進一份可捲動的歷史裡——headers、raw body、query string、時序——而且會留著，方便你幾個小時後再回來看。一個 replay 按鈕可以重送任何一條已擷取的請求，這正是它不只是被動檢視器的原因。

什麼時候用它

• 觀察一連串事件。 一則訊息可能先扇出 message.received，再跟著好幾條 message.status.updated。RequestBin 把它們按順序鋪開，你就能確認整串事件都到齊了。
• 橫跨好幾分鐘的驗證流程。 QR 碼和配對流程會先後發出 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 更適合你想要一份持久、可捲動、橫跨一段時間的多條投遞歷史的時候。