HTTP Webhook 認証

前提条件

Webhook プロバイダーによっては、ハンドシェイクが必要な場合があります。チャレンジ検証の設定方法の詳細については、「 Webhook チャレンジ検証 」セクションを参照してください。

トリガーを作成した場所に応じて、生成された Webhook URL は [HTTP Webhook トリガー] アクティビティまたはトリガーの作成ページに表示されますが、これはコネクションが正常に作成された後にのみです。失敗を避けるため、ワークフローのパブリッシュ後、または UiPath Orchestrator でトリガーが正常に作成された後に、アプリケーションに Webhook URL を貼り付けます。

HTTP Webhook 接続を作成する

1. Select Orchestrator from the product launcher.
2. Select a folder, and then navigate to the Connections tab.
3. [ コネクションを追加] を選択します。
4. To open the connection creation page, select the connector from the list. You can use the search bar to find the connector.
5. [ この Webhook はどのアプリケーションですか ] フィールドに、Webhook アプリケーションのわかりやすい名前を入力します。これにより、このコネクションがどのベンダーまたは連携に属しているかを簡単に識別できます。この値が 接続識別子になります。
6. チャレンジの場所を設定する
   UiPath が正しく対応できるよう、ベンダーがチャレンジ トークンを送信する方法を選択します。
   • チャレンジなし - ベンダーはハンドシェイクを必要とせず、接続に進むことができます。
   • クエリ パラメーター (例: ?challenge=...)
   • JSON 本文 (POST と { "challenge": "..." })
   • ヘッダー (例: X-Hub-Challenge)
7. 本人確認検証の設定と接続
   ベンダーがハンドシェイクを必要とする場合は、ベンダーのパターン(読み取るフィールド/ヘッダー/クエリーと、それをエコー/検証する方法)に一致する チャレンジ検証 を入力します。設定が完了したら、[ 接続] をクリックします。

ヒント:

• 混乱を避けるため、ベンダーと環境を含む名前 (Stripe-prod や Slack-staging など) を使用してください。
• ベンダーが使用しているチャレンジ パターンがわからない場合は、ベンダーの Webhook ドキュメントを確認するか、テスト登録を実行してハンドシェイク リクエストを検査します。

Webhook チャレンジの検証

一部のベンダーは、実際のイベントの送信を開始する前に、Webhook URL の検証を要求しています。これは、チャレンジ レスポンス メカニズムを使用して行われます。Webhook を登録すると、ベンダーは特別なチャレンジ要求を送信し、エンドポイントは期待どおりに正確に応答する必要があります。

HTTP Webhook コネクタは、 Webhook チャレンジ フレームワークを介してこれらの検証フローをサポートしており、UiPath がベンダーのチャレンジをどのように読み取って対応するかを設定できます。

チャレンジ検証のサポート

UiPath では、ベンダー Webhook の両方の種類の動作がサポートされています。

• チャレンジ検証を使用していないベンダー
• Webhook をアクティブ化する前にチャレンジ ハンドシェイクを必要とするベンダー

これにより、単純な Webhook プロバイダーだけでなく、より高度なセキュリティ要件を持つプロバイダーにも対応できます。

ベンダーがチャレンジ検証を使用しない場合

多くのアプリケーションは、Webhook URL を受け入れるだけで、すぐにイベントの配信を開始します。
これらのベンダーの場合:

• ユーザーは 、コネクションを作成または選択するだけです。
• Webhook URL をコピーします。
• これをベンダーの Webhook 設定に貼り付けます。

追加の手順は不要です。Webhook は、ベンダーがイベントの送信を開始するとすぐにアクティブになります。

これは最も一般的でシンプルなシナリオであり、UiPath はシームレスに処理します。

ベンダー が チャレンジ検証を要求する場合

一部のベンダーは、Webhook URL を有効化する前に、その URL を検証するための チャレンジ リクエスト を送信します。
これらのケースでは、次のようになります。

• ユーザーは、HTTP Webhook 接続で チャレンジ応答を設定する必要があります 。
• UiPath はベンダーのチャレンジ要求をリッスンします。
• UiPath は、設定に基づいて正しいチャレンジ値を自動的に返します。
• ベンダーが応答を検証すると、通常のイベントが流れ始めます。

チャレンジの送信方法 (クエリ パラメーター、JSON 本文、ヘッダーなど) はベンダーによって異なるため、UiPath の設定ではこれらのパターンをすべて処理できます。

これにより、Slack、Meta (Facebook/Instagram)、Stripe など、セキュリティ ハンドシェイクを適用する Webhook プロバイダーとの相互運用性が確保されます。

チャレンジ検証の設定

チャレンジ動作は、次の 4 つのパラメーターを使用して設定します。

• チャレンジ キー
  チャレンジ値を含むフィールド/キー。チャレンジ要求を検出するために使用します (null にすることはできません)。

• チャレンジの場所
  キーが表示される場所:

  • 本文
  • クエリ パラメーター
  • ヘッダー

• チャレンジ応答コンテンツの種類
  ベンダーに返される応答の形式:

  • テキスト/プレーン
  • application/json

• チャレンジ応答の形式
  返される値を定義します (通常はチャレンジ キー自体)。
  UiPath は、受信したチャレンジから値を抽出し、それに応じて回答します。

一般的な例

受信要求

 {
  "challenge": "ABC123"
 }

構成

• チャレンジキー: challenge != null
• チャレンジ場所:ボディ
• 応答の種類: text/plain
• 応答の形式: challenge

レスポンス

ABC123

WhatsAppチャレンジ検証の例

WhatsApp は、 hub.challenge でクエリパラメータベースのチャレンジメソッドを使用します。

構成

パラメーター	値 (Value)
チャレンジ キー	hub.challenge != null
チャレンジの場所	クエリ パラメーター
チャレンジ応答コンテンツの種類	text/plain
チャレンジ応答の形式	hub.challenge

仕入先要求

GET https://your-webhook-url?hub.challenge=1234567890

UiPath の期待される回答

HTTP/1.1 200 OK
Content-Type: text/plain

1234567890

これにより所有権が確認され、WhatsAppはその後、実際のWebhookイベントの送信を開始します。

概要—ジェネリックとWhatsApp

手順	一般的な例	WhatsAppの例
チャレンジの場所	本文/クエリ/ヘッダー	クエリ
キーフォーマット	単純キー (例: challenge)	ドット付きのキー ("hub.challenge")
応答の種類	text/plain または application/json	テキスト/プレーン
応答値	キーの値	値 "hub.challenge"
メソッド	POST または GET	GET のみ