webhook.site で UnifyPort webhook をデバッグする

何をしてくれるのか

webhook.site を開いた瞬間、使い捨ての HTTPS URL がもらえます。その URL に POST されたものは——curl のワンライナーから本番 webhook まで——dashboard に headers、生 body、query string、タイミング込みで表示されます。サインアップも不要、インストールも不要。無料版で URL は 1 週間保持、有料版ならもっと長く。

UnifyPort 連携で出番が来るとき

正直に言えば：問題はこちら側ではなく UnifyPort 側かもしれない、と疑ったとき。具体的には次の三つの場面で頻出します：

• 1. 最初の疎通確認。本物のハンドラを組み終える前に、デバイスの webhook エンドポイントを webhook.site の URL に向けて、テストメッセージをトリガーします。届けば、疎通・アカウント連携・プロバイダセッションの三段すべて健康ということです。
• 2. 抜け落ちた事件の照合。本来届くはずのイベント（例えば Telegram の message.received）がハンドラに来ないとき、臨時にもう一つ target を追加して webhook.site に向けてください。あちらに届いてこちらに来ないならバグはあなたのコードに、両方とも届かないなら delivery id を添えてチケットを切りましょう。
• 3. 忘れていたフィールドの確認。Dashboard には私たちが投げる正規化済みの JSON が丸ごと表示されます——data.attendees、data.conversation.title といった、毎回出るとは限らないオプションフィールドも含めて。ドキュメントを読み返すより速い。

X-Device-Signature を見つける

target に署名シークレットが設定されている場合、すべての配信に三つのカスタムヘッダがつきます：

三つとも webhook.site の Headers パネルに表示されます。コードを書く前に署名が正しいか確認したいなら、timestamp と生 body をコピーして私たちの CyberChef ガイド に流し込んでください——あなたのシークレットで算出した hex がヘッダと 1 バイト単位で一致するはずです。

使ってはいけないとき

本番トラフィックに近い何か：実際の顧客メッセージ、本当に使っている署名シークレット、他人のサーバに残したくない PII。webhook.site の URL は推測可能で公開状態と想定すべし——貼った瞬間に誰にでも読まれる可能性があります。実アカウント相手に長期間デバッグするなら smee.io や自前 bin に切り替えましょう。

私たちが好きな代替

• Pipedream RequestBin——数時間にわたる遅いトラフィックを観察したいとき向き。
• smee.io——キャプチャだけでなく localhost に転送してくれる、ローカル開発ループに向く。
• ngrok——フルなローカルトンネル、127.0.0.1:4040 に inspector 内蔵。実装中に一番開くのはこれ。