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. Select Add connection.
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 のみ