Webhook Tester

Webhook テスターとは、そこへ送られたすべての HTTP リクエストを記録する一時的な公開アドレスであり、Webhook の送信者が実際に何を配信したかを正確に確認できます。以下でフックを作成すると、30 分間有効な一意の URL が得られます。Stripe、GitHub、決済プロバイダー、監視サービス、または自前のコードをその URL に向け、イベントをトリガーすれば、すべての配信がここに届きます——メソッド、パスとクエリ、ヘッダー、ボディ、送信元アドレス——本物のハンドラーを接続する前に検査できます。

最終更新:

このサービスが保存するもの——そして決してしないこと

フックを作成すると、SysOSX チェッカーサーバーにはフック ID、作成時刻と有効期限、作成者のアドレスだけが保存されます。キャプチャされた各リクエストは、到着時刻、メソッド、クエリ文字列を含むパス、送信されたそのままのヘッダー、最大 256 KB までのボディ（それを超える部分は切り捨てられ、その旨が表示されます）、そして送信者のアドレスを保存します。1 つのフックが保持できるのは最大 50 リクエストまでで、それを超える配信は有効期限まで拒否されます。すべてはフック作成から 30 分後に削除されるか、削除ボタンを押した時点で即座に削除されます。レシーバーは受信するだけです。何かを取得したり、追跡したり、再生したりすることは決してありません——キャプチャされたリクエストが外部への呼び出しを引き起こすことはありません。隣のデバッグツールについては HTTP ステータスチェーントレーサー を、ワークフロー全体については 配管なしで Webhook をデバッグする をお読みください。

レシーバーがないと Webhook のデバッグが面倒な理由

Webhook とは、他人のサーバーが、相手のスケジュールで、あなたがコントロールできないイベント——支払いの成功、プッシュの到着、アラートの発火——に応答して、あなたのサーバーを呼び出す仕組みです。この形こそが Webhook のデバッグを厄介にしています。送信者はあなたのノートパソコンに到達できないため、実際の配信を 1 件でも見るには、ローカル開発にトンネルや公開ステージングマシンが必要です。イベントは 2 回トリガーするのが難しい場合があり、得られた唯一の配信は完全にキャプチャしておく必要があります。そして何かが失敗したとき、送信者のダッシュボードには通常、あなたのエンドポイントが返したステータスコードしか表示されず、実際に何が送られたかは表示されません。署名ヘッダーはあったのか。ボディはドキュメントが約束した JSON の形だったのか、それともフォームエンコードされていたのか。再試行は同じイベント ID を送ったのか。ハンドラーがログに残す前にリクエストを拒否してしまった場合——Webhook デバッグを支配する署名と解析のバグではまさにそれが起こります——これらの疑問にハンドラーのログだけでは答えられません。

一時レシーバーは、そのループから配管を取り除きます。何が到着するかを見るためだけに書きかけのハンドラーをデプロイする代わりに、すべてを受け入れ、忠実に記録し、あなたに見せるアドレスを作成します。到着した順序と大文字小文字そのままのヘッダー、どのパーサーにも拒否される前の生のボディ、送信者がパラメーターを隠すことのあるクエリ文字列、そして正確なメソッド——プロバイダーによって POST で配信するもの、PUT で配信するもの、GET でヘルスチェックするものがあるからです。本物のキャプチャ済み配信が 1 件画面にあれば、ドキュメントではなく真実に即してハンドラーを書くことができ、実際のペイロードからテスト用フィクスチャを構築し、失敗した再試行とオリジナルを並べて比較できます。その後フックを削除し、プロバイダーを本物のエンドポイントに向けて、もう一度イベントをトリガーし、自前のハンドラーが応答するのを見ます。30 分は意図的に短く設定されています。デバッグセッションには十分な長さで、キャプチャ済みペイロードでいっぱいの忘れられたテストアドレスがインターネット上に残り続けないだけの短さです。

よくある質問

フックの寿命はどれくらいで、どれだけキャプチャできますか？

フックは作成した瞬間から 30 分間有効で、その後フックとキャプチャしたすべてが自動的に削除されます。保持できるのは最大 50 リクエストまでで、それを超える配信はフックの有効期限まで 429 応答で拒否されます。各リクエストボディは最大 256 KB まで保存されます——それより長いボディは切り捨てられ、キャプチャには切り捨てられた旨の表示が付くので、すべてを見ているわけではないことが分かります。

私のフックがキャプチャした内容は誰が見られますか？

フック URL を知っている人なら誰でも見られます。URL の中の ID が唯一の資格情報であり、リクエストの送信とキャプチャの閲覧の両方を認可します。その上にアカウントもパスワードもありません。それがこのツールが即座に使える理由であり、URL をパスワードのように扱うべき理由でもあります——公開投稿したり、秘密情報や個人データを含む本番トラフィックをこのような共有ビューアーに向けたりしないでください。

レシーバーは送信者に返信したり、リンクをたどったり、リクエストを再生したりしますか？

しません。レシーバーは受け入れた配信ごとに、到着したことを記録する小さな 200 JSON の確認応答を返すだけで、それ以外は何もしません。ペイロードの中に見つかった URL を取得することは決してなく、リダイレクトをたどることもなく、再生や転送も提供しません。受信と検査がサービスのすべてであり、キャプチャされたペイロードが外部トラフィックに変わることを防ぎます。

どのような送信者をテストできますか？

公開 URL へ HTTP リクエストを送信できるものすべてです。Stripe、GitHub、Shopify、決済・フォームプロバイダー、監視・CI サービス、IoT デバイス、あるいは curl を使った自前のコードなどです。フックを作成し、プロバイダーの Webhook 設定（またはスクリプト）に URL を貼り、イベントをトリガーすれば、数秒以内に配信がここに到着するのを確認できます。後でプロバイダーからテスト URL を削除するか、本物のハンドラーに向けることを忘れないでください。