n8nのWebhookを設定する｜テストURL・本番URL・届かない原因を整理

n8nのWebhookは、外部から届くHTTPリクエストをworkflowの入口にします。まずテストURLで入力を読み、本番URL・公開状態・認証を揃えてから外部サービスの送信先へ登録します。

テストURLと本番URLを使い分ける

Webhookノードを追加し、受け付けるHTTPメソッドとPathを設定します。フォームからJSONを受ける例ならPOSTを使います。ノードに表示されるURLをコピーし、自分でテスト用のパスを本番用へ書き換えないでください。

テストURLは、エディターでテストイベントの待受を始めた状態で使います。本番URLは、workflowを公開して自動実行できる状態にしてから使います。両者の扱いはWebhookの公式仕様にまとまっています。

最初のリクエストは、架空の一件だけにする

{
  "request_id": "demo-webhook-001",
  "category": "support",
  "message": "試験用の問い合わせです"
}

受信後はOUTPUTのJSONを開き、本文がどこへ入ったかを確認します。後続が本文のrequest_idを読むつもりでも、入力全体の直下に値があるとは限りません。実際の構造を見てから項目を参照します。

この段階では、受信内容を確認するノードだけをつなぎます。誰でも入口へ送れる状態のまま、投稿公開・削除・課金などの操作へ直接つなげないようにします。

HTTPの応答と、仕事の完了を区別する

受信直後に応答する構成では、送信元が成功応答を受け取った後で、workflowの処理が失敗する場合があります。長い処理なら受付IDを返して結果を別に照会するなど、受付と完了を分ける設計が必要です。

届かない場合は、URL・メソッド・待受から確認する

1. 送信先がテストURLか本番URLかを確認する。
2. テストの待受、または本番の公開状態を確認する。
3. 送信メソッドとノードの設定を照合する。
4. HTTP応答を記録し、認証・TLS・プロキシの設定を確認する。
5. 受信した実行があるなら、最初に失敗したノードを見る。

URLを知っていることだけを認証にしません。送信元に合わせた認証設定を使い、秘密情報を実行記録へ残しすぎないようにします。再送する外部サービスには、同じIDを二回処理しない仕組みも組み合わせてください。