用 webhook.site debug UnifyPort webhook

佢究竟做啲乜

一打開 webhook.site 就即刻畀你一個臨時 HTTPS URL。任何打到呢個 URL 嘅請求——一行 curl 命令又得，真正 production webhook 又得——都會喺 dashboard 出現，完整睇到 headers、原始 body、query string 同時序。唔使註冊、唔使裝。免費版 URL 保留一星期，畀錢版仲長啲。

UnifyPort 整合裡面幾時用佢

坦白講：每次你懷疑問題可能唔係喺你嗰邊、係喺我哋呢邊嗰陣。具體嚟講有三個常見時機：

• 1. 第一次接通性確認。喺真正 handler 寫好之前，將個 device 嘅 webhook endpoint 指向 webhook.site URL，觸發一條 test 訊息。事件能到嘅話，即係 connectivity、帳號綁定、provider session 三條線都正常。
• 2. 對比唔見咗嘅事件。當你 handler 冇收到本應收到嘅事件（譬如 Telegram message.received），臨時加多個 target 指去 webhook.site。如果嗰邊收到、你呢邊收唔到，bug 喺你 code 度；兩邊都收唔到，開 ticket 時帶住 delivery id。
• 3. 睇下啲你已經唔記得仲有嘅 field。Dashboard 會 show 出我哋投遞嘅完整 normalized JSON——包括 data.attendees、data.conversation.title 呢啲唔係每個事件都有嘅 optional field。快過揭文檔。

認得 X-Device-Signature

當 target 配咗 signing secret 嗰陣，每次投遞都會帶三個 custom header：

三個都會喺 webhook.site 嘅 Headers 面板度出現。如果仲未想寫 code 但想驗證簽章係咪啱，攞 timestamp 同 raw body 去跑一次我哋嘅 CyberChef 教學，用你嘅 secret 算出嚟嘅 hex 應該同 header 一個字一個字咁配到。

幾時唔好用佢

任何貼近 production traffic 嘅情況：真實客戶訊息、你而家用緊嘅 signing secret、唔應該留喺人哋 server 嘅 PII。webhook.site 嘅 URL 係可以估到、公開嘅——當你 paste 嘢上去，當人哋都睇到咁諗。要長時間跑、對真帳號做 debug 時，轉去 smee.io 或者自架 bin。

我哋都鍾意嘅替代品

• Pipedream RequestBin——要睇幾個鐘流量嗰陣較啱。
• smee.io——係 forward 去 localhost，唔淨止捕獲，較啱本地開發 loop。
• ngrok——完整嘅本地 tunnel，127.0.0.1:4040 內置 inspector。真正 dev 嗰陣我哋開得最多就係呢個。

常見問題

webhook.site 用喺 production webhook 安唔安全？

唔安全。webhook.site 嘅 URL 估得到、個 dashboard 又係公開嘅——任何知道條 URL 嘅人都睇到每一個捕獲到嘅請求。淨係用嚟做原型、配啲用完即棄嘅 secret 或者唔含 PII 嘅測試事件先好用。要對真嘅 UnifyPort 帳號長時間做 debug，就轉去 smee.io 或者自架 bin。

webhook.site 條 URL 可以維持幾耐？

免費版七日；畀錢 plan 仲長。條 URL 喺到期之前、或者你喺 dashboard 手動刪除之前都一直有效——即係話一個 bin 唔使換都可以捕獲跨幾次測試 session 嘅流量。

webhook.site 會唔會自動幫 UnifyPort 驗證簽章？

唔會。webhook.site 淨係 show 出 X-Device-Signature header 嘅值——佢唔會重新計 HMAC。想證明個簽章配得到，攞 bin 入面嘅 timestamp 同 raw body，連埋你嘅 signing secret 一齊放入我哋嘅 CyberChef recipe；算出嚟嘅 hex 應該同 header 一個字節一個字節咁完全一樣。