用 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——完整本地通道，127.0.0.1:4040 內建 inspector。實際開發時我們開得最多的就是這個。