Authentification HTTP Webhook

Connectez UiPath à votre fournisseur de Webhook et configurez la vérification des défis de Webhook ou l’authentification basée sur l’en-tête.

Prérequis

Votre fournisseur de Webhook peut avoir besoin d’établir une liaison. Reportez-vous à la section Vérification du défi de webhook pour plus de détails sur la façon de configurer la vérification des défis.

Selon l’endroit où vous créez le déclencheur, l’URL du webhook générée apparaîtra dans l’activité de déclencheur HTTP Webhook ou sur la page de création du déclencheur, mais uniquement après la création de la connexion avec succès. Pour éviter les échecs, collez l’URL du webhook dans votre application après avoir publié votre workflow, ou bien le déclencheur a été créé avec succès dans UiPath Orchestrator.

Création d'une connexion HTTP Webhook

1. Sélectionnez Orchestrator dans le lanceur du produit.

2. Sélectionnez un dossier, puis accédez à l'onglet Connexions .

3. Sélectionnez Ajouter une connexion (Add connecion).

4. Pour ouvrir la page de création de connexion, sélectionnez le connecteur dans la liste. Vous pouvez utiliser la barre de recherche pour trouver le connecteur.

5. Dans le champ Pour quelle application est ce Webhook , saisissez un nom descriptif pour l’application de Webhook, quelque chose qui facilite l’identification du fournisseur ou de l’intégration que cette connexion représente. Cette valeur devient l' identificateur de connexion.

6. (Facultatif) Configurez l’authentification basée sur l’en-tête.

   Si vous souhaitez qu’UiPath valide chaque demande de Webhook entrant, dans la liste déroulante Type d’authentification sélectionnez Authentification basée sur l’en-tête, puis spécifiez:

   • Clé d'en-tête — l'en-tête HTTP utilisé par le fournisseur pour envoyer les informations d'identification (par exemple, X-API-Key ou X-API-Secret).
   • Valeur de l’en-tête — la valeur du secret que le fournisseur envoie dans cet en-tête (par exemple, a1b2c3d4e5f6789...). Ce champ est masqué et stocké en toute sécurité. Vous pouvez également utiliser une ressource d'informations d’identification pour ce champ.

   Configurez la même clé et la même valeur d’en-tête dans les paramètres du webhook du fournisseur. Si les valeurs ne correspondent pas au moment du runtime, UiPath rejettera la requête avec HTTP 401.

   Pour plus d'informations, consultez Authentification de l'en-tête Webhook.

7. Configurer l'emplacement du défi
   Choisissez la façon dont le fournisseur enverra le jeton de défi afin qu'UiPath puisse répondre correctement :

   • Aucun défi : le fournisseur n'a pas besoin d'établir la liaison et vous pouvez procéder à la connexion.
   • Paramètre de requête (par exemple, ?challenge=...)
   • Corps JSON (PUBLIER avec { "challenge": "..." })
   • En-tête (par ex., X-Hub-Challenge)

8. Configurer la vérification du défi et se connecter
   Si le fournisseur requiert un processus d'établissement de liaison, saisissez la vérification de défi qui correspond au modèle du fournisseur (le champ/l'en-tête/la requête à lire et comment l'écho/la valider). Une fois la configuration terminée, sélectionnez Connecter.

   Lorsque cette option est disponible, sélectionnez le menu à côté d'un champ et choisissez Utiliser la ressource d'informations d’identification ou Utiliser la ressource Orchestrator pour référencer une ressource Orchestrator au lieu d'entrer directement la valeur. Pour plus d'informations, consultez Utiliser des ressources d'informations d'identification pour les connexions.

Astuce :

• Utilisez un nom qui inclut le fournisseur et l’environnement (par exemple, Stripe-prod ou Slack-staging) pour éviter toute confusion.
• Si vous ne savez pas quel modèle de défi le fournisseur utilise, vérifiez les documents de son webhook ou exécutez un enregistrement de test pour inspecter la demande d'établissement de liaison.

Vérification du défi de webhook

Certains fournisseurs exigent que les URL du webhook soient validées avant de commencer à envoyer des événements réels. Cela se fait à l'aide d'un mécanisme de défi-réponse. Lorsque vous enregistrez un webhook, le fournisseur envoie une demande de défi spécial et le point de terminaison doit répondre exactement comme prévu.

Le connecteur HTTP Webhook prend en charge ces flux de vérification via l' infrastructure des défis Webhook, vous permettant de configurer la façon dont UiPath doit lire et répondre aux défis des fournisseurs.

Prise en charge de la vérification des défis

UiPath prend en charge les deux types de comportements Webhooks des fournisseurs :

• Fournisseurs qui n’utilisent pas la vérification des défis
• Les fournisseurs qui ont besoin d’établir une liaison de défi avant d’activer le Webhook

Cela garantit la compatibilité avec les fournisseurs de webhooks simples ainsi que ceux avec des exigences de sécurité plus avancées.

Lorsque les fournisseurs n'utilisent pas la vérification des défis

De nombreuses applications acceptent simplement une URL de webhook et commencent immédiatement à fournir des événements.
Pour ces fournisseurs :

• Les utilisateurs n'ont qu'à créer ou sélectionner une connexion.
• Copiez l’ URL du webhook.
• Collez-le dans la configuration du webhook du fournisseur.

Aucune étape supplémentaire n'est nécessaire. Le Webhook devient actif dès que le fournisseur commence à envoyer des événements.

Il s'agit du scénario le plus courant et le plus simple, et UiPath le gère de manière transparente.

Lorsque les fournisseurs ont besoin de vérification des difficultés

Certains fournisseurs envoient une requête de défi pour vérifier l’URL du webhook avant de l’activer.
Dans ces cas :

• Les utilisateurs doivent configurer la réponse au défi dans la connexion HTTP Webhook.
• UiPath écoute la demande de défi du fournisseur.
• UiPath renvoie automatiquement la valeur de défi correcte en fonction de la configuration.
• Une fois que le fournisseur a validé la réponse, les événements normaux commencent à se produire.

Étant donné que les fournisseurs diffèrent dans la façon dont ils envoient le défi (paramètre de requête, corps JSON, en-tête, etc.), la configuration de UiPath permet aux utilisateurs de gérer n'importe lequel de ces modèles.

Cela garantit la compatibilité avec les fournisseurs de Webhooks qui appliquent les liaisons de sécurité tels que Slack, Meta (Facebook/Instangram), Stripe et autres.

Configurer la vérification des défis

Vous pouvez configurer le comportement au défi à l'aide de quatre paramètres :

• Clé de défi
  Champ/clé contenant la valeur du défi. Utilisé pour détecter les requêtes de défi.

• Emplacement du défi
  Où la clé apparaît :

  • Corps
  • Paramètre de requête
  • En-tête

• Type de contenu de réponse de défi
  Format de la réponse renvoyée au fournisseur :

  • texte/Brute
  • application/json

• Format de réponse de défi
  Définit la valeur renvoyée (en général la clé de défi elle-même).
  UiPath extrait la valeur du défi entrant et répond en conséquence.

Exemples de configuration de défis

Exemple générique

Demande entrante

 {
  "challenge": "ABC123"
 }

Configuration

• Clé de défi : challenge != null
• Emplacement du défi : Corps
• Type de réponse : text/plain
• Format de réponse : challenge

Réponse

ABC123

Exemple de vérification de défi Whatsapp

WhatsApp utilise la méthode de défi basée sur les paramètres de requête avec hub.challenge.

Configuration

Paramètre	Valeur (Value)
Clé de défi	hub.challenge != null
Emplacement du défi	Paramètre de requête
Type de contenu de réponse de défi	text/plain
Format de réponse de défi	hub.challenge

Demande du fournisseur

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

Réponse attendue d’UiPath

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

1234567890

Cela confirme la propriété et WhatsApp commencera par la suite à envoyer de vrais événements de webhook.

Résumé — Générique et Whatsapp

Étape	Exemple générique	Exemple de Whatsapp
Emplacement du défi	Corps/Requête/En-tête	Requête
Format de clé	Clé simple (par exemple, challenge)	Clé avec un point "hub.challenge")
ResponseType	texte/IA ou application/json	texte/Brute
Valeur de la réponse	Valeur de la clé	Valeur de "hub.challenge"
Method	POST ou GET	OBTENIR uniquement

Exemples par modèle de fournisseur

Exemple 1 : un défi de corps simple avec une réponse textuelle

Envois du fournisseur

{"challenge":"abc123","type":"url_verification"}

Champ	Valeur (Value)
Emplacement du défi	Body
Clé de défi	challenge
Type de contenu de la réponse du défi	text
Format de la réponse de défi	challenge

Réponse : abc123 (texte/Brut, 200)

Exemple 2 : défi de paramètre de requête avec réponse textuelle

Envois du fournisseur

GET /webhook?challenge=CHALLENGE_STRING

Champ	Valeur (Value)
Emplacement du défi	Query Parameter
Clé de défi	challenge
Type de contenu de la réponse du défi	text
Format de la réponse de défi	challenge

Réponse : CHALLENGE_STRING (texte/Brut, 200)

Exemple 3 : défi du corps avec réponse JSON

Envois du fournisseur

{"challenge":"abc123"}

Champ	Valeur (Value)
Emplacement du défi	Body
Clé de défi	challenge
Type de contenu de la réponse du défi	json
Format de la réponse de défi	{ "challenge": "challenge" }

Réponse : {"challenge":"abc123"} (application/json, 200)

Exemple 4 : chemin d'accès au corps imbriqué (par exemple, verification.token) avec la réponse textuelle

Envois du fournisseur

{"verification":{"token":"abc123"}}

Champ	Valeur (Value)
Emplacement du défi	Body
Clé de défi	verification.token
Type de contenu de la réponse du défi	text
Format de la réponse de défi	verification.token

Réponse : abc123 (texte/Brut, 200)

Exemple 5 : Chemin profondément imbriqué avec réponse JSON

Envois du fournisseur

{"event":{"challenge":"abc123","type":"verify"}}

Champ	Valeur (Value)
Emplacement du défi	Body
Clé de défi	event.challenge
Type de contenu de la réponse du défi	json
Format de la réponse de défi	{ "result": "event.challenge" }

Réponse : {"result":"abc123"} (application/json, 200)

Exemple 6 : un défi basé sur une en-tête avec une réponse textuelle

Envois du fournisseur

POST /webhook x-webhook-challenge: abc123

Champ	Valeur (Value)
Emplacement du défi	Header
Clé de défi	"x-webhook-challenge"
Type de contenu de la réponse du défi	text
Format de la réponse de défi	"x-webhook-challenge"

Réponse : abc123 (texte/Brut, 200)

Remarque :

Le nom de l’en-tête contient des traits d’union, qui peuvent être interprétés comme des opérateurs dans l’analyse des contextes. L'encapsulage de l'identifiant dans des guillemets doubles (par exemple, "x-webhook-challenge") garantit qu'il est traité comme un nom de clé littérale. Utilisez toujours des guillemets doubles autour d'un identifiant contenant des traits d'union, des points ou d'autres caractères spéciaux.

Exemple 7 : détection booléenne avec une clé de réponse différente

Envois du fournisseur

{"type":"url_verification","challenge":"abc","token":"legacytoken"}

Souhaitez-vous détecter par le champ type , mais répondez avec la valeur challenge .

Champ	Valeur (Value)
Emplacement du défi	body
Clé de défi	type == vérification_URL
Type de contenu de la réponse du défi	json
Format de la réponse de défi	{ "challenge": "challenge" }

Réponse : {"challenge":"abc"} (application/json, 200)

Authentification de l'en-tête de Webhook

L’authentification basée sur l’en-tête permet à UiPath de valider chaque demande de Webhook entrant par rapport à une clé secrète partagée que vous avez configurée lors de la création de la connexion. Cela empêche les appelants non autorisés de déclencher vos workflows en publiant votre URL Webhook.

Mode de fonctionnement

Lorsque l’authentification basée sur l’en-tête est activée sur une connexion, Integration Service:

1. Vérifie chaque demande entrante pour la clé d'en-tête configurée.
2. Accepte l’événement si l’en-tête est présent et que sa valeur correspond au secret stocké.
3. Renvoie HTTP 401 Non autorisé et ne déclenche aucun workflow si l'en-tête est absent ou si sa valeur ne correspond pas.

Exemple de requête acceptée par UiPath:

POST /webhook HTTP/1.1
Host: <your-uipath-webhook-url>
X-API-Key: a1b2c3d4e5f6789...
Content-Type: application/json

{ "event": "..." }

Exemple de requête rejetée par UiPath (en-tête manquant ou valeur incorrecte):

HTTP/1.1 401 Unauthorized

Champs de configuration

Le tableau suivant décrit les champs qui permettent de configurer l'authentification de l'en-tête Webhook sur l'écran de création de la connexion.

Champ	Description	Exemple
Type d’authentification	Active ou désactive la validation des en-têtes pour cette connexion.	Header Based Authentication / None
Clé d’en-tête	Nom de l’en-tête HTTP envoyé par le fournisseur.	X-API-Key, X-API-Secret
Valeur de l’en-tête	La valeur secrète que le fournisseur envoie dans cet en-tête. Masqué au repos.	a1b2c3d4e5f6789...

Compatibilité des fournisseurs

L’authentification basée sur l’en-tête ne fonctionne qu’avec les fournisseurs qui vous permettent de configurer un en-tête HTTP personnalisé sur les livraisons de webhook sortantes.

Si vous ne savez pas si votre fournisseur prend en charge les en-têtes personnalisés sortants, consultez la documentation Webhook du fournisseur.

Mise à jour ou rotation de la clé secrète

Lorsque vous modifiez la connexion et modifiez la valeur de l'en-tête, la nouvelle valeur prend effet immédiatement pour tous les déclencheurs utilisant cette connexion. La configuration du fournisseur doit être mise à jour avec la nouvelle valeur au même moment, ou les livraisons du fournisseur échoueront avec HTTP 401 tant que vous ne le faireez pas.

Comportement en cas d’échec de l’authentification

Une demande est rejetée avec HTTP 401 Non autorisé si:

• L'en-tête attendu est absent de la requête.
• L’en-tête est présent, mais sa valeur ne correspond pas à la clé secrète stockée.

Les demandes échouées ne sont pas réessayées par UiPath et aucun événement de déclencheur n’est envoyé. Le propre comportement de réessai du fournisseur (le cas échéant) s'applique.

Les traçages d'échec d'authentification peuvent être consultés dans la section Traçages . Pour aider à protéger nos systèmes contre les attaques DoS, les traces d'échec d'authentification sont limitées à 5 par heure.

Remarque importante

• L'authentification basée sur l'en-tête est définie sur l'étendue de la connexion. Tous les déclencheurs créés pour la même connexion partagent la même clé et la même valeur d'en-tête; la mise à jour du secret de la connexion affecte chaque déclencheur qui l'utilise.
• L’authentification basée sur l’en-tête est indépendante de la vérification des défis. L’une ou l’autre, les deux, ou l’aucune ne peut être activée sur une connexion.
• La valeur de l’en-tête est stockée chiffrée et doit être gérée avec la même attention que tout autre identifiant.
• Les noms d’en-tête ne sont pas sensibles à la casse selon la spécification HTTP (X-API-Key et x-api-key sont équivalents).