Webhooks

Les webhooks sont des services qui hébergent votre logique métier ou appellent d'autres services. Au cours d'une session, les webhooks vous permettent d'utiliser les données extraites par le traitement du langage naturel des agents conversationnels (Dialogflow CX) pour générer des réponses dynamiques, valider les données collectées ou déclencher des actions sur le backend.

Un webhook peut être un webhook standard ou un webhook flexible. Avec un webhook standard, les champs de requête et de réponse sont définis par les agents de conversation (Dialogflow CX). Avec un webhook flexible, vous définissez les champs de requête et de réponse.

Webhooks standards

Avec les webhooks standards, vous utilisez des messages de requête et de réponse définis par les agents de conversation (Dialogflow CX). Le message de requête fournit de nombreuses informations sur la session. Par exemple, la page active actuelle, l'intent correspondant récent, les valeurs des paramètres de session et les réponses définies par l'agent sont tous inclus.

Requête de webhook standard

Lorsqu'un fulfillment avec un webhook est appelé, les agents conversationnels (Dialogflow CX) envoient une requête de webhook POST HTTPS à votre service de webhook. Le corps de cette requête est un objet JSON WebhookRequest contenant des informations sur la session.

Certaines intégrations renseignent le champ WebhookRequest.payload avec des informations supplémentaires. Par exemple, l'intégration de la passerelle de téléphonie Dialogflow CX fournit l'ID de l'appelant de l'utilisateur final.

Pour en savoir plus, consultez la documentation de référence sur WebhookRequest(V3) ou WebhookRequest(V3Beta1).

Réponse webhook standard

Une fois que votre service webhook a reçu une requête de webhook, il doit envoyer une réponse de webhook. Les limites suivantes s'appliquent à votre réponse :

  • La réponse doit se produire dans un délai d'expiration que vous configurez lors de la création de la ressource de webhook, sinon la requête expirera.
  • La taille de la réponse doit être inférieure ou égale à 64 Kio.

Pour en savoir plus, consultez la documentation de référence sur WebhookResponse(V3) ou WebhookResponse(V3Beta1).

Paramètres des ressources webhook standards

Vous trouverez ci-dessous la description des paramètres de ressource webhook pour les webhooks standards:

Terme Définition
Nom à afficher Nom affiché dans la console pour le webhook.
Délai avant expiration du webhook Lorsque les agents de conversation (Dialogflow CX) envoient une requête de webhook à votre service de webhook, il est possible que le délai avant expiration soit dépassé en attendant une réponse. Ce paramètre contrôle ce délai avant expiration, en secondes. En cas de délai avant expiration, les agents de conversation (Dialogflow CX) appellent un événement webhook.error.timeout.
Type Définissez la valeur sur Service directory (Annuaire des services) si vous utilisez l'annuaire des services pour l'accès privé au réseau, sinon définissez la valeur sur Generic web service (Service Web générique).
URL du webhook Indiquez l'URL de votre service de webhook.
Sous-type Définissez-le sur Standard.
Webhook spécifique à l'environnement Vous pouvez fournir des webhooks spécifiques à l'environnement.
Authentification Consultez la section sur l'authentification.
Certificat CA personnalisé Il permet d'importer des certificats d'autorité de certification personnalisés.

Webhooks flexibles

Avec les webhooks flexibles, vous définissez la méthode HTTP de la requête, les paramètres d'URL de la requête et les champs des messages de requête et de réponse. La requête ne peut fournir que des valeurs de paramètre sélectionnées, et la réponse ne peut fournir que des valeurs de forçage de paramètre. Cette limitation est en fait bénéfique, car elle simplifie l'interface entre l'agent et le webhook. Il est rarement nécessaire de communiquer autre chose que les valeurs des paramètres de session entre un agent et un webhook. Cela simplifie également l'implémentation de votre webhook, car les messages de requête et de réponse ne contiennent que ce dont vous avez besoin, et vous pouvez fournir des messages de webhook uniques pour différents scénarios.

Requête de webhook flexible

Lorsque vous créez la ressource de webhook pour votre agent, vous pouvez spécifier les éléments suivants pour les requêtes de webhook:

  • Méthode HTTP utilisée pour les requêtes webhook envoyées à votre service de webhook.
  • Valeurs de paramètre de session que les agents de conversation (Dialogflow CX) doivent envoyer à votre service de webhook à l'aide de l'URL.
  • Si vous choisissez POST, PUT ou PATCH comme méthode, vous pouvez spécifier les valeurs de paramètre de session que les agents de conversation (Dialogflow CX) doivent envoyer à votre service webhook via le corps JSON de la requête.

Pour envoyer des valeurs de paramètres de session à l'aide de l'URL de la requête ou du corps JSON, utilisez des références de paramètres comme vous le feriez normalement. Vous n'avez pas besoin d'échapper la référence de paramètre en URL et vous ne devez pas l'encapsuler entre guillemets. Au moment de l'exécution, les agents de conversation (Dialogflow CX) échapperont la valeur du paramètre en tant qu'URL si nécessaire. Une liste ou une valeur composite sera fournie au format JSON.

Lorsque vous utilisez une référence de paramètre dans le corps JSON, vous devez l'encapsuler entre guillemets, quel que soit le type du paramètre. Si le paramètre est en fait une valeur scalaire, une liste ou une valeur composite numérique, les agents conversationnels (Dialogflow CX) supprimeront les guillemets lors de l'envoi de la requête au moment de l'exécution pour préserver le type de données du paramètre. Les types scalaires de chaîne resteront entre guillemets. Si une valeur scalaire, une liste ou une valeur composite numérique est référencée dans une valeur de chaîne (par exemple, "Il s'agit d'un nombre : $session.params.size"), le paramètre sera traité comme une chaîne ("Il s'agit d'un nombre : 3").

Par exemple, vous pouvez fournir les valeurs des paramètres de session fruit et size à l'URL de la requête comme suit:

https://your-webhook-service.com/handler?f=$session.params.fruit&s=$session.params.size

Et au corps de la requête JSON comme suit:

{
  "fruitParameter": "$session.params.fruit",
  "sizeParameter": "$session.params.size"
}

Réponse webhook flexible

Lorsque vous créez la ressource webhook pour votre agent, vous pouvez spécifier des paramètres de session que les agents conversationnels (Dialogflow CX) doivent définir sur des champs spécifiques de la réponse du webhook au moment de l'exécution.

Les limites suivantes s'appliquent à votre réponse :

  • La réponse doit se produire dans un délai d'expiration que vous configurez lors de la création de la ressource de webhook, sinon la requête expirera.
  • La taille de la réponse doit être inférieure ou égale à 64 Kio.

Utilisez le format suivant pour spécifier un champ scalaire, une liste ou un champ composite:

$.fully.qualified.path.to.field

Par exemple, examinons la réponse JSON suivante:

{
  "routes" : [
    {
      "legs" : [
        {
          "distance" : {
            "text" : "2,064 mi",
            "value" : 3321004
          }
        }
      ]
    }
  ]
}

Pour spécifier le champ "value", utilisez ce qui suit:

$.routes[0].legs[0].distance.value

Paramètres flexibles des ressources de webhook

Vous trouverez ci-dessous la description des paramètres de ressources webhook pour les webhook flexibles:

Terme Définition
Nom à afficher Nom affiché dans la console pour le webhook.
Délai avant expiration du webhook Lorsque les agents de conversation (Dialogflow CX) envoient une requête de webhook à votre service de webhook, il est possible que le délai avant expiration soit dépassé en attendant une réponse. Ce paramètre contrôle ce délai avant expiration, en secondes. En cas de délai avant expiration, les agents de conversation (Dialogflow CX) appellent un événement webhook.error.timeout.
Type Définissez la valeur sur Service directory (Annuaire des services) si vous utilisez l'annuaire des services pour l'accès privé au réseau, sinon définissez la valeur sur Generic web service (Service Web générique).
URL du webhook Indiquez l'URL de votre service webhook, qui peut inclure des références à des paramètres de session.
Sous-type Définissez sur Flexible
Méthode Définissez la méthode HTTP de la requête webhook.
Corps de la requête Fournissez le corps JSON de la requête comme décrit ci-dessus.
Configuration de la réponse Indiquez les paramètres de session à définir sur les champs de réponse comme décrit ci-dessus.
Webhook spécifique à l'environnement Vous pouvez fournir des webhooks spécifiques à l'environnement.
Authentification Consultez la section sur l'authentification.
Certificat CA personnalisé Il permet d'importer des certificats d'autorité de certification personnalisés.

Utiliser un modèle personnalisé prédéfini

Dialogflow propose des modèles personnalisés prédéfinis que vous pouvez utiliser pour intégrer des webhooks flexibles au CRM Salesforce.

  1. Dans l'onglet Gérer, cliquez sur Webhooks, puis sur + Créer.

  2. Sous Sous-type, sélectionnez Flexible.

  3. Cliquez sur Configurer à l'aide d'un modèle prédéfini pour activer cette fonctionnalité.

  4. Dans le menu déroulant Type d'intégration, sélectionnez Salesforce.

  5. Dans le menu déroulant Nom de l'API, sélectionnez un nom d'API. Le modèle remplit automatiquement le formulaire de webhook en fonction du nom de l'API que vous choisissez.

    1. Vous pouvez configurer manuellement les champs suivants, le cas échéant, en fonction de vos paramètres:

      • URL du webhook
      • Méthode
      • Corps JSON de la requête
      • Configuration de la réponse
    2. Les champs OAuth obligatoires sont mis en surbrillance dans la section Authentification.

  6. Cliquez sur Enregistrer pour créer le webhook.

Conditions requises pour le service de webhook

Votre service de webhook doit remplir les conditions suivantes :

Authentification

Il est important de sécuriser votre service de webhook, de sorte que vous seul ou votre agent Conversational Agents (Dialogflow CX) soyez autorisé à effectuer des requêtes. Cette configuration se fait lors de la création ou de la modification d'une ressource webhook. Les agents de conversation (Dialogflow CX) sont compatibles avec les mécanismes d'authentification suivants:

Terme Définition
En-têtes d'authentification Pour les paramètres du webhook, vous pouvez spécifier des paires clé-valeur d'en-tête HTTP facultatives. Si vous les fournissez, les agents de conversation (Dialogflow CX) ajoutent ces en-têtes HTTP aux requêtes de webhook. Il est courant de fournir une seule paire avec une clé authorization. Les valeurs d'en-tête sont compatibles avec les références de paramètres de session et l'analyse des fonctions système, comme dans les messages de réponse statiques. Si vous utilisez des identifiants statiques pour l'en-tête authorization, nous vous recommandons de fournir vos identifiants à l'aide de Secret Manager.
Authentification de base avec nom d'utilisateur et mot de passe Pour les paramètres du webhook, vous pouvez spécifier des valeurs facultatives pour le nom d'utilisateur et le mot de passe de connexion. Si vous le fournissez, les agents de conversation (Dialogflow CX) ajoutent un en-tête HTTP d'autorisation aux requêtes de webhook. Cet en-tête se présente sous la forme suivante: "authorization: Basic <base 64 encoding of the string username:password>". Nous vous recommandons de fournir votre nom d'utilisateur et votre mot de passe à l'aide de Secret Manager.
OAuth tiers Vous pouvez spécifier la configuration OAuth tierce afin que les agents de conversation (Dialogflow CX) échangent un jeton d'accès à partir du système OAuth et l'ajoutent dans l'en-tête HTTP d'autorisation. Seul le flux des identifiants client est accepté. Nous vous recommandons de fournir votre code secret du client à l'aide de Secret Manager.
Jetons d'accès de l'agent de service Abandonnées
Compte de service Vous pouvez utiliser un compte de service pour l'authentification. Vous pouvez l'utiliser pour accéder à d'autres API Google Cloud.
Jetons d'ID d'agent de service Vous pouvez sélectionner le jeton d'ID dans l'authentification de l'agent de service pour utiliser des jetons d'ID d'agent de service pour l'authentification. Vous pouvez l'utiliser pour accéder aux ressources Cloud Run.
Authentification TLS mutuelle Consultez la documentation sur l'authentification TLS mutuelle.

OAuth tiers

Les agents de conversation (Dialogflow CX) peuvent collecter un jeton d'accès auprès d'un fournisseur OAuth tiers et l'ajouter à l'en-tête HTTP d'autorisation lorsqu'ils envoient leurs requêtes webhook.

Vous trouverez ci-dessous la description des paramètres de ressources pour OAuth tiers:

Terme Définition
ID client ID client à utiliser lors de la demande d'un jeton OAuth.
Code secret du client Code secret à utiliser lors de la demande d'un jeton OAuth. Nous vous recommandons de fournir votre code secret du client à l'aide de Secret Manager.
URL du point de terminaison OAuth URL à utiliser pour demander un jeton OAuth.
Champs d'application OAuth Liste des champs d'application pour lesquels le jeton OAuth peut être utilisé, séparés par une virgule.

Les requêtes envoyées à l'URL du point de terminaison OAuth pour recevoir un jeton n'incluent pas les en-têtes de requête personnalisés configurés pour la requête webhook. Vous pouvez transmettre des informations personnalisées au serveur OAuth en tant que paramètres dans la chaîne de requête de l'URL du point de terminaison OAuth.

Jeton d'ID d'agent de service

Les agents de conversation (Dialogflow CX) peuvent générer un jeton d'ID à l'aide de l'agent de service des agents de conversation (Dialogflow CX).

Le jeton est ajouté dans l'en-tête HTTP d'autorisation lorsque les agents de conversation (Dialogflow CX) appellent un webhook.

Un jeton d'ID peut être utilisé pour accéder aux ressources Cloud Run après avoir accordé des autorisations de rôle d'appelant à

service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com
Si les ressources Cloud Run se trouvent dans le même projet de ressources, vous n'avez pas besoin d'autorisation IAM supplémentaire pour les appeler.

L'audience utilisée pour générer le jeton d'ID correspond à l'URL complète du webhook, à l'exception des paramètres de requête. Si vous utilisez Cloud Run, assurez-vous que cette URL est compatible avec les audiences Cloud Run. Par exemple, si l'URL du webhook est

https://myproject.cloudfunctions.net/my-function/method1?query=value

L'URL suivante doit figurer dans les audiences personnalisées.

https://myproject.cloudfunctions.net/my-function/method1

Tout webhook peut également valider le jeton à l'aide de bibliothèques clientes Google ou de bibliothèques Open Source telles que github.com/googleapis/google-auth-library-nodejs.

Compte de service

Les comptes de service peuvent être utilisés pour authentifier les requêtes webhook auprès de toutes les API Google compatibles.

Si ce n'est pas déjà fait, créez un compte de service.

Comme les comptes de service sont des comptes principaux, ils peuvent accéder aux ressources de votre projet en leur attribuant un rôle, comme vous le feriez pour n'importe quel autre compte principal. L'adresse e-mail du compte de service sera utilisée pour générer un jeton d'accès qui sera envoyé dans l'en-tête Authorization de la requête webhook.

L'utilisateur qui configure le webhook pour utiliser des comptes de service doit disposer des autorisations suivantes:

  • roles/iam.serviceAccountUser

Pour que les agents de conversation (Dialogflow CX) puissent générer des jetons, l'agent de service Dialogflow doit disposer des autorisations suivantes:

  • roles/iam.serviceAccountTokenCreator

Le compte de service doit également disposer d'autorisations pour accéder au service qui héberge le webhook.

Authentification Secret Manager

Si vous utilisez des en-têtes d'authentification, une authentification de base avec un nom d'utilisateur et un mot de passe, ou OAuth tiers, vous pouvez stocker les identifiants en tant que secrets à l'aide de Secret Manager. Voici les étapes nécessaires pour authentifier votre webhook à l'aide de secrets:

  1. Créez votre secret si vous n'en avez pas déjà un.
  2. Attribuez au Agent de service Dialogflow le rôle Accesseur de secrets Secret Manager (roles/secretmanager.secretAccessor) pour le nouveau secret.
  3. Copiez vos identifiants dans le presse-papiers.
  4. Ajoutez une nouvelle version de secret à votre secret. Collez vos identifiants en tant que valeur du secret.
    • Si vous utilisez des en-têtes d'authentification, saisissez Bearer <YOUR_CREDENTIAL>.
    • Si vous utilisez l'authentification de base par nom d'utilisateur et mot de passe, saisissez plutôt <YOUR_USERNAME>:<YOUR_PASSWORD>.
    • Omettre tout caractère de nouvelle ligne à la fin.
  5. Copiez le nom de la version du secret que vous venez d'ajouter. Le format du nom est projects/{project_id}/secrets/{secret_id}/versions/{version_id}".
  6. Ouvrez l'écran de modification du webhook, puis :
    • Si vous utilisez des en-têtes d'authentification, créez un en-tête de requête de version de secret. Saisissez "Authorization" (Autorisation) comme Key (Clé), puis collez le nom de la version du secret dans la zone de saisie Secret version (Version du secret).
    • Si vous utilisez l'authentification de base par nom d'utilisateur et mot de passe, cliquez sur Version de secret sous Authentification de base, puis collez le nom de la version de secret dans la zone de saisie Version de secret.
    • Si vous utilisez OAuth tiers, cliquez sur Version du secret sous OAuth tiers, puis collez le nom de la version du secret dans le champ de saisie Version du secret.
  7. Cliquez sur Enregistrer.

Validation des certificats HTTPS

Les agents de conversation (Dialogflow CX) utilisent par défaut le trust store par défaut de Google pour valider les certificats HTTPS. Si vous avez l'intention d'utiliser des certificats non reconnus par le magasin de confiance par défaut de Google pour votre serveur HTTPS, tels que des certificats autosignés ou des certificats racines personnalisés, consultez la pageCertificats CA personnalisés.

Webhooks spécifiques à l'environnement

Si vous utilisez des environnements pour isoler les systèmes de production des systèmes de développement (recommandé), vous pouvez configurer vos webhooks pour qu'ils soient spécifiques à l'environnement. Pour chaque ressource webhook que vous définissez, vous pouvez fournir une URL et des paramètres d'authentification uniques pour chaque environnement que vous avez défini pour l'agent.

Vous pouvez ainsi développer et tester de manière sécurisée les mises à jour de votre code de webhook avant de les déployer en production.

Créer ou modifier des ressources de webhook

Une fois que vous avez un service de webhook en cours d'exécution, vous devez créer une ressource de webhook contenant les informations de connectivité et d'authentification. Une fois la ressource webhook créée, vous pouvez également modifier ses paramètres à tout moment.

Pour créer ou modifier une ressource de webhook:

Console

  1. Ouvrez la console Dialogflow CX.
  2. Choisissez votre projet Google Cloud.
  3. Sélectionnez votre agent.
  4. Sélectionnez l'onglet Gérer.
  5. Cliquez sur Webhooks.
  6. Cliquez sur Créer ou sur une ressource webhook dans la liste pour la modifier.
  7. Saisissez les paramètres de ressource webhook standard ou les paramètres de ressource webhook flexibles.
  8. Cliquez sur Enregistrer.

API

Pour créer une ressource de webhook, consultez la méthode create pour le type Webhook. Pour modifier une ressource webhook (à l'exception des paramètres spécifiques à l'environnement), consultez la méthode patch ou update pour le type Webhook.

Sélectionnez un protocole et une version pour la référence du webhook :

Protocole V3 V3beta1
REST Ressource Webhook Ressource Webhook
RPC Interface du webhook Interface du webhook
C++ WebhooksClient Non disponible
C# WebhooksClient Non disponible
Go WebhooksClient Non disponible
Java WebhooksClient WebhooksClient
Node.js WebhooksClient WebhooksClient
PHP Non disponible Non disponible
Python WebhooksClient WebhooksClient
Ruby Non disponible Non disponible

Pour modifier les paramètres spécifiques à l'environnement d'un webhook, consultez la méthode patch ou update pour le type Environment.

Sélectionnez un protocole et une version pour la référence de l'environnement :

Protocole V3 V3beta1
REST Ressource de l'environnement Ressource de l'environnement
RPC Interface de l'environnement Interface de l'environnement
C++ EnvironmentsClient Non disponible
C# EnvironmentsClient Non disponible
Go EnvironmentsClient Non disponible
Java EnvironmentsClient EnvironmentsClient
Node.js EnvironmentsClient EnvironmentsClient
PHP Non disponible Non disponible
Python EnvironmentsClient EnvironmentsClient
Ruby Non disponible Non disponible

Erreurs de webhook

Si votre service de webhook rencontre une erreur lors du traitement d'une requête de webhook, votre code de webhook doit renvoyer l'un des codes d'état HTTP suivants :

  • 400 Requête incorrecte
  • 401 Opération non autorisée
  • 403 Interdit
  • 404 Introuvable
  • 500 Panne du serveur
  • 503 Service indisponible

Dans les situations d'erreur suivantes, les agents de conversation (Dialogflow CX) appellent une erreur de webhook ou un événement intégré, et continuent le traitement comme d'habitude:

  • Expiration du délai de réponse
  • Code d'état d'erreur reçu
  • Réponse non valide
  • Service de webhook non disponible

En outre, si l'appel de service de webhook a été déclenché par un appel d'API de détection d'intent, le champ queryResult.webhookStatuses de la réponse de détection d'intent contient les informations d'état du webhook.

Nouvelles tentatives automatiques

Les agents de conversation (Dialogflow CX) incluent des mécanismes internes qui réessayent automatiquement en cas d'erreurs de webhook spécifiques afin d'améliorer la robustesse. Seules les erreurs non terminales sont réessayées (par exemple, les erreurs de délai avant expiration ou de connexion).

Pour réduire la probabilité d'appels en double:

  • Définissez des seuils de délai avant expiration plus longs pour les webhooks.
  • Assurez-vous que la logique du webhook est idempotente ou dédupliquez-la.

Utiliser Cloud Run

Les agents de conversation (Dialogflow CX) s'intègrent à Cloud Run pour vous permettre de créer un webhook sécurisé sans serveur. Si vous créez une ressource Cloud Run qui se trouve dans le même projet que votre agent, sélectionnez Authentification de l'agent de service -> Jeton d'ID dans la configuration d'authentification afin que votre agent puisse appeler votre webhook de manière sécurisée.

Toutefois, il existe deux situations dans lesquelles vous devez configurer manuellement cette intégration:

  1. Le compte de service Agent de service Agents de conversation (Dialogflow CX) avec l'adresse suivante doit exister pour votre projet d'agent:
    service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com
    Ce compte de service spécial et la clé associée sont normalement créés automatiquement lorsque vous créez le premier agent pour un projet. Si votre agent a été créé avant le 1er novembre 2020, vous pouvez déclencher la création de ce compte de service spécial :
    1. Créez un agent pour le projet.
    2. Exécutez la commande suivante :
      gcloud beta services identity create --service=dialogflow.googleapis.com --project=agent-project-id
  2. Si votre fonction de webhook se trouve dans un projet différent de celui de l'agent, vous devez fournir le rôle IAM Demandeur Cloud Run ou Demandeur Cloud Functions à l'agent de service des agents conversationnels (Dialogflow CX) dans le projet de votre ressource Cloud Run.
  3. Sélectionnez Authentification de l'agent de service -> Jeton d'identité dans la section "Configuration de l'authentification".

Utiliser des webhooks conteneurisés et le framework ezcx Go

Si vous souhaitez implémenter un webhook conteneurisé à l'aide de Go, consultez le framework ezcx Go. Ce framework peut simplifier de nombreuses étapes requises lors de la création d'un webhook.

Utiliser Cloud Run avec un trafic interne uniquement

Les ressources Cloud Run configurées pour accepter le trafic interne provenant des réseaux VPC du même projet ou du même périmètre VPC Service Controls peuvent être utilisées comme webhook tant que l'agent se trouve dans le même projet ou le même périmètre VPC Service Controls.

Utiliser l'Annuaire des services pour l'accès privé au réseau

Les agents conversationnels (Dialogflow CX) s'intègrent à l'accès au réseau privé de l'Annuaire des services pour pouvoir se connecter aux cibles de webhooks dans votre réseau VPC. Cela permet de conserver le trafic au sein du réseau Google Cloud et d'appliquer IAM et VPC Service Controls.

Pour configurer un webhook ciblant un réseau privé, procédez comme suit :

  1. Suivez la page sur la configuration du réseau privé de l'Annuaire des services pour configurer votre réseau VPC et le point de terminaison de l'Annuaire des services.

  2. Le compte de service Agent de service Agents de conversation (Dialogflow CX) avec l'adresse suivante doit exister pour votre projet d'agent:

    service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com

    Attribuez les rôles suivants au compte de service Agent de service des agents conversationnels (Dialogflow CX) dans le projet où se trouve votre Annuaire des services:

    • servicedirectory.viewer
    • servicedirectory.pscAuthorizedService

    De plus, si votre Annuaire des services se trouve dans un projet différent de celui de votre agent Dialogflow CX, vous devez également accorder le rôle servicedirectory.viewer au compte d'agent de service des agents conversationnels (Dialogflow CX) dans le projet qui héberge votre agent Dialogflow CX.

  3. Fournissez le service d'annuaire du service avec l'URL et les informations d'authentification facultatives lors de la création du webhook.

    Console

    Capture d&#39;écran du webhook de l&#39;Annuaire des services

    API

    Consultez le champ serviceDirectory pour le type Webhook.

    Sélectionnez un protocole et une version pour la référence du webhook :

    Protocole V3 V3beta1
    REST Ressource Webhook Ressource Webhook
    RPC Interface du webhook Interface du webhook
    C++ WebhooksClient Non disponible
    C# WebhooksClient Non disponible
    Go WebhooksClient Non disponible
    Java WebhooksClient WebhooksClient
    Node.js WebhooksClient WebhooksClient
    PHP Non disponible Non disponible
    Python WebhooksClient WebhooksClient
    Ruby Non disponible Non disponible

Pour résoudre les problèmes, vous pouvez configurer un test de disponibilité privé pour vérifier que votre annuaire des services est correctement configuré.

Exemples et dépannage

Consultez le guide d'utilisation des webhooks.