Présentation des webhooks

Rechercher

Présentation

Un webhook est une requête HTTPS définie par l’utilisateur qui est déclenchée lorsqu’un événement souscrit se produit sur le site source (Adobe Acrobat Sign dans ce cas).

Un webhook n’est rien d’autre qu’un service REST qui accepte des données ou un flux de données.

Les webhooks sont destinés à la communication entre services dans un Modèle PUSH.

Lorsqu’un événement souscrit se déclenche, Acrobat Sign crée une requête HTTPS POST avec un corps JSON et la transmet à l’URL spécifiée.

Avant de configurer les webhooks, assurez-vous que votre réseau accepte les plages d’adresses IP nécessaires à la fonctionnalité.

 

Les webhooks offrent plusieurs avantages par rapport à la méthode de rappel précédente :

  • Les administrateurs peuvent activer leurs webhooks sans avoir à impliquer l’assistance Acrobat Sign pour répertorier l’URL de rappel.
  • Les webhooks sont meilleurs en matière d’actualisation des données, d’efficacité de la communication et de sécurité. Aucune interrogation n’est requise.
  • Les webhooks permettent de définir facilement différents niveaux de portée (compte/groupe/utilisateur/ressource). 
  • Les webhooks constituent une solution d’API plus moderne, permettant une configuration plus directe des applications modernes.
  • Plusieurs webhooks peuvent être configurés par portée (compte/groupe/utilisateur/ressource) alors que les rappels doivent impérativement être uniques.
  • Les webhooks permettent de sélectionner les données à retourner, là où les rappels sont une solution de type « tout ou rien ».
  • Les métadonnées transférées avec un webhook peuvent être configurées (de base ou détaillées).
  • Les webhooks sont beaucoup plus faciles à créer, modifier ou désactiver selon les besoins, car leur interface utilisateur est entièrement sous le contrôle de l’administrateur.
Remarque :

Ce document porte principalement sur l’interface utilisateur Webhooks dans l’application web Acrobat Sign (auparavant Adobe Sign).

Les développeurs qui recherchent des détails sur l’API trouveront des informations supplémentaires ici :

Conditions préalables

Vous devez autoriser les plages d’adresses IP pour les webhooks via votre sécurité réseau pour que le service fonctionne. 

Le service d’URL de rappel hérité dans REST v5 utilise les mêmes plages d’adresses IP que le service de webhook.

Les administrateurs peuvent se connecter à l’Adobe Admin Console pour ajouter des utilisateurs. Une fois connecté, accédez au menu de l’administrateur et faites défiler jusqu’à Webhooks.

Se connecter à l’Admin Console

Utilisation

Les administrateurs doivent d’abord disposer d’un service webhook prêt à accepter le transfert entrant depuis Acrobat Sign. Il existe de nombreuses options à cet égard, et tant que le service peut accepter les requêtes POST et GET, le webhook est efficace.

Une fois le service en place, un administrateur Acrobat Sign peut créer un webhook à partir de l’interface Webhook dans le menu Compte du site Acrobat Sign.

Les administrateurs peuvent configurer le webhook pour qu’il se déclenche pour des événements d’accord, de formulaire web (widget) ou d’envoi en masse (Mega Sign). La ressource Modèle de bibliothèque (Document de bibliothèque) peut également être configurée via l’API.

La portée du webhook peut inclure l’ensemble du compte ou des groupes individuels via l’interface d’administration. L’API permet une plus grande granularité grâce à la sélection des portées UTILISATEUR ou RESSOURCE.

Le type de données envoyé vers l’URL est configurable et peut inclure les éléments suivants : Informations sur l’accord, Informations sur les participants, Informations sur les documents, etc.

Une fois le webhook configuré et enregistré, Acrobat Sign envoie un nouvel objet JSON à l’URL définie à chaque déclenchement de l’événement souscrit. Aucune manipulation en cours du webhook n’est requise, sauf si vous souhaitez modifier les critères de déclenchement d’événement ou la payload JSON.

Vérification de l’intention de l’URL du webhook

Avant d’enregistrer un webhook, Acrobat Sign vérifie si son URL indiquée dans la demande d’enregistrement est destinée à recevoir des notifications ou non. À cette fin, lorsqu’Acrobat Sign reçoit une nouvelle demande d’enregistrement de webhook, il envoie d’abord une demande de vérification à l’URL du webhook. Cette demande de vérification est une requête HTTPS GET envoyée à l’URL du webhook. Elle comporte un en-tête HTTP personnalisé : X-AdobeSign-ClientId. La valeur de cet en-tête est définie sur l’ID client (ID de l’application) de l’application API qui demande la création/l’enregistrement du webhook. Pour enregistrer un webhook, l’URL de celui-ci doit répondre à cette demande de vérification avec un code de réponse 2XX. De plus, elle DOIT renvoyer la même valeur d’ID client de l’une des deux façons suivantes :

  • Soit dans un en-tête de réponse X-AdobeSign-ClientId. Il s’agit du même en-tête transmis dans la demande et repris dans la réponse.
  • Soit dans le corps de la réponse JSON avec la clé X-AdobeSign-ClientId. Sa valeur correspond à l’ID client envoyé dans la demande.

Le webhook est enregistré uniquement si la réponse est positive (code de réponse 2XX) et si la validation de l’ID client figure dans l’en-tête ou le corps de la réponse. L’objectif de cette demande de vérification est de démontrer que vous souhaitez recevoir des notifications à cette URL de webhook. Si vous avez saisi une URL incorrecte par inadvertance, celle-ci ne peut pas répondre correctement à la demande de vérification de l’intention, et Acrobat Sign n’envoie aucune notification à cette URL. En outre, l’URL du webhook peut également confirmer la réception des notifications uniquement via les webhooks enregistrés par une application spécifique. Pour ce faire, validez l’ID client de l’application transmis dans l’en-tête X-AdobeSign-ClientId. Si l’URL du webhook ne reconnaît pas cet ID client, elle NE DOIT PAS répondre avec le code de réponse positive, et Acrobat Sign doit s’assurer que l’URL n’est pas enregistrée en tant que webhook.

La vérification de l’appel de l’URL du webhook est effectuée dans les scénarios suivants :

  • Enregistrement du webhook : si la vérification de l’appel de l’URL du webhook échoue, le webhook n’est pas créé.
  • Mise à jour du webhook : INACTIF vers ACTIF : si la vérification de l’appel de l’URL du webhook échoue, l’état du webhook ne devient pas ACTIF.

Réponse à une notification du webhook

Acrobat Sign effectue une vérification implicite de l’intention dans chaque demande de notification de webhook envoyée à l’URL du webhook. Ainsi, chaque requête HTTPS de notification de webhook contient également l’en-tête HTTP personnalisé appelé X-AdobeSign-ClientId. La valeur de cet en-tête est l’ID client (ID de l’application) de l’application qui a créé le webhook. Nous considérons que la notification du webhook a été correctement distribuée si, et uniquement si, une réponse positive (code de réponse 2XX) est retournée et si l’ID client est envoyé dans l’en-tête HTTP (X-AdobeSign-ClientId) ou dans un corps de réponse JSON avec la clé xAdobeSignClientId et une valeur identique à l’ID client. Dans un cas contraire, nous réessayons de distribuer la notification à l’URL du webhook jusqu’à épuisement des tentatives.

Comme mentionné ci-dessus, la valeur de l’en-tête (ID client) X-AdobeSign-ClientId qui est inclus dans chaque demande de notification de Sign doit être reprise dans la réponse de deux manières :

1. En-tête HTTP X-AdobeSign-ClientId et valeur identique à l’ID client

Exemple de code JavaScript permettant de récupérer l’ID client, de le valider, puis de le retourner dans l’en-tête de réponse

// Fetch client id

var clientid = request.headers['X-ADOBESIGN-CLIENTID'];

 

//Validate it

if (clientid ==="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    //Return it in response header

    response.headers['X-AdobeSign-ClientId'] = clientid;

    response.status = 200;  // default value

}

Exemple de code PHP permettant de récupérer l’ID client, de le valider, puis de le retourner dans l’en-tête de réponse

<?php

// Fetch client id

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validate it

if($clientid == "BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    //Return it in response header

   header("X-AdobeSign-ClientId:$clientid");

   header("HTTP/1.1 200 OK"); // default value

}

?>


2. Corps de la réponse JSON avec la clé xAdobeSignClientId et la valeur identique à l’ID client

Exemple de code JavaScript permettant de récupérer l’ID client, de le valider, puis de le retourner dans le corps de la réponse

// Fetch client id

var clientid = request.headers['X-ADOBESIGN-CLIENTID'];

 

 

//Validate it

if (clientid ==="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    var responseBody = {

                         "xAdobeSignClientId" : clientid // Return Client Id in the body

                       };

    response.headers['Content-Type'] = 'application/json';

    response.body = responseBody;

    response.status = 200;

}

Exemple de code PHP permettant de récupérer l’ID client, de le valider, puis de le retourner dans le corps de la réponse

<?php

// Fetch client id

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validate it

if($clientid == "BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

   //Return it in response body

   header("Content-Type: application/json");

   $body = array('xAdobeSignClientId' => $clientid);

   echo json_encode($body);

   header("HTTP/1.1 200 OK"); // default value

}

?>

Exemple de corps de la réponse JSON

{

    "xAdobeSignClientId": "BGBQIIE7H253K6"

}

Conditions préalables

Vous avez besoin des éléments suivants :

  1. Un compte Microsoft doté d’une licence pour créer des applications Azure Functions.
  2. Une application Azure Function existante. Vous pouvez en créer une en consultant l’article https://docs.microsoft.com/fr-fr/azure/azure-functions/functions-create-first-azure-function. 
  3. Connaissances de base de JavaScript, afin que vous puissiez comprendre et écrire le code dans le langage de votre choix.

Procédure de création d’un déclencheur Azure Functions faisant office de webhook Acrobat Sign

Pour créer une fonction Déclencheur HTTP JavaScript :

1. Connectez-vous via votre compte Microsoft https://portal.azure.com/.

2. Ouvrez l’application Azure Function affichée dans l’onglet Applications de fonctions.

Accès aux Applications de fonctions dans Azure

La liste d’applications Azure Functions s’ouvre :

3. Sélectionnez l’application dans laquelle vous souhaitez créer cette fonction.

4. Cliquez sur le bouton Créer (+) pour créer une fonction Azure.

Création d’une fonction Azure

 

5. Sélectionnez le scénario Webhook + API et le langage JavaScript.

6. Cliquez sur Créer cette fonction.

Une nouvelle fonction capable de gérer une demande d’API entrante est créée.

Ajout d’une logique pour enregistrer un webhook Acrobat Sign.

Avant d’enregistrer un webhook, Acrobat Sign vérifie que l’URL du webhook indiquée dans la demande d’enregistrement est réellement destinée à recevoir des notifications ou non. À cette fin, lorsqu’une nouvelle demande d’enregistrement de webhook est reçue par Acrobat Sign, l’application envoie d’abord une demande de vérification à l’URL du webhook. Cette demande de vérification est une requête HTTPS GET envoyée à l’URL du webhook avec un en-tête HTTP personnalisé X-AdobeSign-ClientId. La valeur de cet en-tête est définie sur l’ID client de l’application qui demande la création/l’enregistrement du webhook. Pour enregistrer un webhook, l’URL de celui-ci doit répondre à cette demande de vérification avec un code de réponse 2XX. De plus, elle doit renvoyer la même valeur d’ID client de l’une des deux façons suivantes.

Vous pouvez suivre deux options :


Option 1 : transmission de l’ID client dans X-AdobeSign-ClientId en tant qu’en-tête de réponse

Transmettez X-AdobeSign-ClientId dans l’en-tête de réponse. Il s’agit du même en-tête, qui est transmis dans la demande et repris dans la réponse.

Remplacez le fichier Index.js par l’extrait de code suivant :

Remplacement du fichier index.js

module.exports = function (context, req) {

    var clientId = req.headers['x-adobesign-clientid'];

    // Validate that the incoming ClientID is genuine

    if (clientId === '123XXX456') {

        context.res = {

            // status: 200, /* Defaults to 200 */ // any 2XX response is acceptable

            body: "Notification Accepted",

            headers : {

                'x-adobesign-clientid' : req.headers['x-adobesign-clientid']

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Opps!! Illegitimate Call identified"

        };

    }

    context.done();

};

 

Testez le comportement en simulant la demande :

1. Cliquez sur le bouton Tester situé dans l’angle supérieur droit.

2. Effectuez la demande factice.

Test de la fonction

Même si les en-têtes de réponse ne sont pas affichés ci-dessus, vous pouvez les observer par simulation via Postman/DHC ou un autre service.


Option 2 : transmission de l’ID client dans le corps de la réponse avec la clé xAdobeSignClientId

Dans le corps de la réponse JSON avec la clé xAdobeSignClientId, sa valeur correspondant à l’ID client envoyé dans l’en-tête de la demande.

Remplacez le fichier Index.js par l’extrait de code suivant :

Mise à jour du contenu du fichier index.js

module.exports = function (context, req) {

    var clientId = req.headers['x-adobesign-clientid'];

    // Validate that the incoming ClientID is genuine

    if (clientId === '123XXX456') {

        context.res = {

            // status: 200, /* Defaults to 200 */ // any 2XX response is acceptable

            corps: {

                'xAdobeSignClientId' : clientId

            },

            headers : {

                'Content-Type' : 'application/json'

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Opps!! Illegitimate Call identified"

        };

    }

    context.done();

};

 

Testez le comportement en simulant la demande :

1. Cliquez sur le bouton Tester situé dans le coin supérieur droit.

2. Effectuez la demande factice.

Test de la fonction

Notez également qu’un même comportement pour l’ID client est attendu lorsque l’URL du webhook reçoit des notifications POST. 


Prêt à l’emploi

Une fois que vous avez vérifié le comportement, l’URL du webhook fonctionne conformément aux standards Acrobat Sign. Vous pouvez ensuite mettre à jour la logique personnalisée selon vos besoins.

 

Obtention de l’URL de la fonction

  • Cliquez sur Obtenir l’URL de la fonction.
Obtention de l’URL de la fonction

 

Copiez l’URL et utilisez-la pour créer des webhooks dans Acrobat Sign.

Copie de l’URL de fonction

Création de la fonction AWS Lambda

Pour créer une fonction AWS Lambda, connectez-vous à AWS Management Console, puis sélectionnez le service AWS Lambda dans la liste des services.

  • Cliquez sur l’option Créer une fonction Lambda à l’aide de Créer de A à Z.
  • Dans la page Configurer la fonction, saisissez le nom de la fonction « lambdaWebhooks » et sélectionnez Node.js 4.3 comme runtime.
  • Pour Rôle, choisissez un rôle existant ou créez-en un à partir d’un ou de plusieurs modèles.
    • Si vous avez choisi Créer un rôle à partir d’un ou de plusieurs modèles, saisissez un nom de rôle (par exemple role-lamda) et sélectionnez Autorisations Microservices simples dans la liste Modèles de stratégies.
  • Cliquez sur le bouton Créer une fonction.
Création d’une fonction dans AWS

  • Sur la page de la nouvelle fonction AWS Lambda, sélectionnez Modifier le code en ligne comme Type d’entrée de code et gardez le gestionnaire index.handler.
  • Ajout d’une logique pour enregistrer un webhook Acrobat Sign

    Avant d’enregistrer un webhook, Acrobat Sign vérifie que l’URL du webhook indiquée dans la demande d’enregistrement est réellement destinée à recevoir des notifications ou non. À cette fin, lorsqu’une nouvelle demande d’enregistrement de webhook est reçue par Acrobat Sign, l’application envoie d’abord une demande de vérification à l’URL du webhook. Cette demande de vérification est une requête HTTPS GET envoyée à l’URL du webhook avec un en-tête HTTP personnalisé X-AdobeSign-ClientId. La valeur de cet en-tête est définie sur l’ID client de l’application qui demande la création/l’enregistrement du webhook. Pour enregistrer un webhook, l’URL de celui-ci doit répondre à cette demande de vérification avec un code de réponse 2XX. De plus, elle doit renvoyer la même valeur d’ID client de l’une des deux façons suivantes. Notez également qu’un même comportement pour l’ID client est attendu lorsque l’URL du webhook reçoit des notifications POST.

    Suivez l’un des deux cas :

    Cas 1 : transmission de l’ID client dans X-AdobeSign-ClientId en tant qu’en-tête de réponse

    •  Transmettez X-AdobeSign-ClientId dans l’en-tête de réponse. Il s’agit du même en-tête, qui est transmis dans la demande et repris dans la réponse.

      Extrait de code
      Dans le fichier index.js, remplacez l’extrait de code généré automatiquement par le code suivant :

Exemple de code Node.JS permettant de récupérer l’ID client, de le valider, puis de le retourner dans l’en-tête de réponse

exports.handler = function index(event, context, callback) {

  // Fetch client id

  var clientid = event.headers['X-AdobeSign-ClientId'];

 

  //Validate it

  if (clientid =="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

  {

    var response = {

        statusCode: 200,

        headers: {

            "X-AdobeSign-ClientId": clientid

        }

     };

   callback(null,response);

  }

  else {

   callback("Oops!! illegitimate call");

  }

}

 

Cas 2 : transmission de l’ID client dans le corps de la réponse avec la clé xAdobeSignClientId

Dans le corps de la réponse JSON avec la clé xAdobeSignClientId, sa valeur correspondant à l’ID client envoyé dans l’en-tête de la demande.

 

Extrait de code

Remplacez le fichier Index.js par l’extrait de code suivant :

Exemple de code Node.JS permettant de récupérer l’ID client, de le valider, puis de le retourner dans l’en-tête de réponse

exports.handler = function index(event, context, callback) {

 // Fetch client id

 var clientid = event.headers['X-AdobeSign-ClientId'];

  

 //Validate it

 if (clientid =="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

 {

   var responseBody = {

        xAdobeSignClientId : clientid

   };

     

    var response = {

        statusCode: 200,

        body: JSON.stringify(responseBody)

    };

 

   callback(null,response);

 }

 else {

   callback("Opps!! illegitimate call");

  }

}
Mise à jour du contenu du fichier index.js

  • Enregistrez la fonction. La fonction Lambda est créée et prête à l’emploi dans un webhook en temps réel.

 

Configuration d’Amazon API Gateway

Pour rendre cette fonction Lambda accessible au public via une méthode HTTP, nous devons configurer AWS API Gateway à l’aide de notre fonction (créée ci-dessus) en tant que système principal de l’API.

Dans AWS Management Console, sélectionnez API Gateway dans les services AWS et cliquez sur le bouton Créer une API.

Configuration de la passerelle API

  • Dans la page Créer une nouvelle API, sélectionnez Nouvelle API, puis saisissez webhooks comme nom de l’API.
  • Cliquez sur le bouton Créer une API.
  • Sélectionnez la liste déroulante Actions, puis l’option Créer une ressource.
  • Cochez l’option Configurer en tant que ressource de proxy et saisissez validation comme Nom de la ressource et {proxy+} dans le Chemin d’accès de la ressource.
  • Laissez l’option Activer CORS pour API Gateway décochée, puis cliquez sur le bouton Créer une ressource.
  • Laissez le paramètre Proxy de fonction Lambda sélectionné comme Type d’intégration et sélectionnez la zone géographique dans laquelle vous avez créé la fonction Lambda dans la liste déroulante Zone géographique Lambda (il s’agit probablement de la zone géographique dans laquelle vous créez API Gateway).
  • Saisissez validation comme Fonction Lambda, puis cliquez sur le bouton Enregistrer.
  • Dans la fenêtre contextuelle Ajouter une autorisation à la fonction Lambda, sélectionnez OK.

Si toutes les étapes ci-dessus sont exécutées correctement, un affichage semblable à ce qui suit apparaît :

Méthode configurée

Déploiement de l’API

L’étape suivante consiste à déployer cette API afin qu’elle soit prête à être utilisée.

  • Dans la liste déroulante Actions, sélectionnez Déployer l’API.
  • Sélectionnez [Nouvelle étape] dans Étape de déploiement et saisissez prod (ou le nom de votre choix pour identifier cette étape) dans Nom de l’étape.
  • Cliquez sur le bouton Déployer.

L’API est maintenant prête à être utilisée. Vous pouvez trouver l’URL d’appel dans la zone bleue comme indiqué ci-dessous :

Déploiement de l’API

Notez cette URL, car vous devrez la saisir en tant qu’URL de webhook en temps réel.

Prêt à l’emploi

C’est fait. Utilisez l’URL indiquée ci-dessus avec la mention « /{nodeJSfunctionName} » ajoutée en tant qu’URL de webhook dans la requête d’API POST /webhooks.  Une fois que vous avez vérifié le comportement, l’URL du webhook fonctionne conformément aux
standards Acrobat Sign. Vous pouvez ensuite mettre à jour/ajouter la logique personnalisée selon vos besoins.

Activation et désactivation

L’accès à la fonctionnalité Webhooks est activé par défaut pour les comptes Grands comptes.

Les administrateurs de groupe peuvent créer/contrôler les Webhooks qui fonctionnent uniquement au sein de leur groupe.

L’accès à la page Webhooks se trouve dans le volet de gauche du menu Administrateur.

Accès à l’onglet webhooks

Bonnes pratiques

  • Abonnez-vous à des événements spécifiques nécessaires pour limiter le nombre de requêtes HTTPS envoyées au serveur : plus vous créez des webhooks spécifiques, moins vous devrez passer en revue le volume de données.
  • Faites attention aux doublons : si plusieurs applications partagent la même URL de webhook et qu’un même utilisateur est mappé à chaque application, le même événement est envoyé à votre webhook plusieurs fois (une fois par application). Dans certains cas, votre webhook peut recevoir des événements en double. Votre application de webhook doit tolérer les doublons et procéder à une déduplication par ID d’événement.
  • Réagissez toujours rapidement aux webhooks : votre application ne dispose que de cinq secondes pour répondre aux demandes de webhook. Pour la demande de vérification, il s’agit rarement d’un problème, car votre application n’a pas besoin d’effectuer un travail réel pour répondre. Toutefois, pour les demandes de notification, votre application effectue généralement une action qui prend du temps en réponse à la demande. Il est recommandé de travailler sur un thread distinct ou de manière asynchrone en utilisant une file d’attente pour vous assurer de pouvoir répondre dans les cinq secondes.
  • Gérez la simultanéité : lorsqu’un utilisateur effectue plusieurs modifications successives rapides, votre application est susceptible de recevoir plusieurs notifications pour le même utilisateur à peu près au même moment. Si vous n’êtes pas attentif à la façon dont vous gérez la simultanéité, votre application peut se retrouver à traiter les mêmes modifications pour un même utilisateur plusieurs fois. Pour tirer parti des webhooks Acrobat Sign, il est nécessaire de bien comprendre l’utilisation des informations. Veillez à poser des questions : 
    • Quelles données voulez-vous retourner dans la payload ?
    • Qui accédera à ces informations ?
    • Quels seront les décisions ou rapports générés ?
  • Recommandations pour la réception d’un document signé : vous devez prendre en compte plusieurs facteurs pour déterminer comment recevoir un PDF signé d’Acrobat Sign dans votre système de gestion des documents. 

Bien qu’il soit parfaitement acceptable de sélectionner simplement l’option Document signé de l’accord lors de la création d’un webhook, vous pouvez envisager d’utiliser l’API Acrobat Sign pour récupérer les documents lorsqu’un événement déclencheur (tel que le statut de l’accord Terminé) est reçu.

Points à prendre en compte...

Limitation de taille de payload JSON

La taille de la payload JSON est limitée à 10 Mo.

Si un événement génère une payload plus importante, un webhook est déclenché, mais les attributs de paramètres conditionnels, si la demande en contient, sont supprimés pour réduire la taille de la payload. 

L’objet « ConditionalParametersTrimmed » est retourné dans la réponse lorsque cela se produit pour informer le client que les informations conditionalParameters ont été supprimées.

« conditionalParametersTrimmed » est un objet de type tableau contenant les informations sur les touches qui ont été supprimées.

La troncation est effectuée dans l’ordre suivant :

  • includeSignedDocuments
  • includeParticipantsInfo
  • includeDocumentsInfo
  • includeDetailedInfo

Les documents signés sont d’abord tronqués, suivis des informations sur les participants, des informations sur les documents et enfin des informations détaillées.

Cela peut se produire, par exemple, lors d’un événement de fin d’accord, s’il inclut également un document signé (codé en base 64) ou pour un accord comptant plusieurs champs de formulaire.

Notifications du webhook

Les webhooks Acrobat Sign envoient des notifications à l’expéditeur de l’accord et à tout webhook configuré dans le groupe à partir duquel l’accord a été envoyé. Les webhooks dont la portée est au niveau du compte reçoivent tous les événements.

Expéditeur : Utilisateur A | Signataire : Utilisateur B | Destinataire du partage : Utilisateur C

Les utilisateurs A et B se trouvent dans des comptes différents

Les utilisateurs A et C se trouvent dans des comptes différents

Cas d’utilisation

Notification ?

Commentaires/Notes

Le compte de l’utilisateur A a un webhook de niveau COMPTE (créé par l’utilisateur A ou l’administrateur du compte).

Oui

 Un webhook de niveau COMPTE est informé de tous les événements déclenchés dans ce compte.

Le compte de l’utilisateur A a un webhook de niveau GROUPE (créé par l’utilisateur A ou l’administrateur de compte/groupe).

Hypothèse : l’utilisateur A et l’administrateur de groupe se trouvent dans le même groupe.

Oui

 Un webhook de niveau GROUPE est informé de tous les événements déclenchés dans ce groupe.

L’utilisateur A a un webhook de niveau UTILISATEUR .

Oui

 En tant qu’expéditeur, le webhook de niveau UTILISATEUR de l’utilisateur A est déclenché

L’utilisateur A a un webhook de niveau RESSOURCE (pour l’accord envoyé ci-dessus).

Oui

  
     

Le compte de l’utilisateur B a un webhook de niveau COMPTE (créé par l’utilisateur B ou l’administrateur du compte).

Non

Le webhook de niveau COMPTE de l’utilisateur B est considéré comme un webhook de signataire.

Le compte de l’utilisateur B a un webhook de niveau GROUPE (créé par l’utilisateur B ou l’administrateur de compte/groupe).

Hypothèse : l’utilisateur B et l’administrateur de groupe se trouvent dans le même groupe.

Non

Le webhook de niveau GROUPE de l’utilisateur B est considéré comme un webhook de signataire.

L’utilisateur B a un webhook de niveau UTILISATEUR .

Non

Le webhook de niveau UTILISATEUR de l’utilisateur B est considéré comme un webhook de signataire.
     

Le compte de l’utilisateur C a un webhook de niveau COMPTE (créé par l’utilisateur C ou l’administrateur du compte).

Non

Le webhook de niveau COMPTE de l’utilisateur C est considéré comme un webhook non initiateur.

Le compte de l’utilisateur C a un webhook de niveau GROUPE (créé par l’utilisateur C ou l’administrateur de compte/groupe).

Hypothèse : l’utilisateur C et l’administrateur de groupe se trouvent dans le même groupe.

Non

Le webhook de niveau GROUPE de l’utilisateur C est considéré comme un webhook non initiateur.

L’utilisateur C a un webhook de niveau UTILISATEUR .

Non

Le webhook de niveau UTILISATEUR de l’utilisateur C est considéré comme un webhook non initiateur.

Expéditeur : Utilisateur A | Signataire : Utilisateur B | Destinataire du partage : Utilisateur C

Les utilisateurs A, B et C se trouvent dans le même compte

Cas d’utilisation

Notification ?

Remarques

Le compte de l’utilisateur A a un webhook de niveau COMPTE (créé par l’utilisateur A ou l’administrateur du compte).

Oui

 Les webhooks de niveau COMPTE notifient les événements déclenchés par le compte.

Le compte de l’utilisateur A a un webhook de niveau GROUPE (créé par l’utilisateur A ou l’administrateur de compte/groupe).

Hypothèse : l’utilisateur A et l’administrateur de groupe se trouvent dans le même groupe.

Oui

 Les webhooks de niveau GROUPE notifient les événements déclenchés par les utilisateurs de leur groupe.

L’utilisateur A a un webhook de niveau UTILISATEUR .

Oui

 En tant qu’expéditeur, le webhook de niveau Utilisateur de l’utilisateur A est déclenché

L’utilisateur A a un webhook de niveau RESSOURCE (pour l’accord envoyé ci-dessus).

Oui

  
     

Le compte de l’utilisateur B a un webhook de niveau COMPTE (créé par l’utilisateur B ou l’administrateur du compte).

Oui

Comme les utilisateurs A et B se trouvent dans le même compte, un webhook de niveau COMPTE est notifié de tous les événements déclenchés dans ce compte.

Le compte de l’utilisateur B a un webhook de niveau GROUPE (créé par l’utilisateur B ou l’administrateur de compte/groupe).

Hypothèse : l’utilisateur A, l’utilisateur B et l’administrateur de groupe se trouvent dans le même groupe.

Oui

Étant donné que l’utilisateur A et l’utilisateur B font partie du même groupe, un webhook de niveau GROUPE est notifié de tous les événements déclenchés dans ce groupe.

Le compte de l’utilisateur B a un webhook de niveau GROUPE (créé par l’utilisateur B ou l’administrateur de compte/groupe).

Hypothèse : les utilisateurs A et B se trouvent dans différents groupes.

Non

Le webhook de niveau GROUPE de l’utilisateur B est considéré comme un webhook de signataire.

Le webhook de l’utilisateur A (RESSOURCE/UTILISATEUR/GROUPE/COMPTE) sera déclenché.

L’utilisateur B a un webhook de niveau UTILISATEUR .

Non

En tant que destinataire, le webhook de niveau UTILISATEUR de l’utilisateur B n’est pas déclenché.
     

Le compte de l’utilisateur C a un webhook de niveau COMPTE (créé par l’utilisateur C ou l’administrateur du compte).

Oui

Comme l’utilisateur A et l’utilisateur C se trouvent dans le même compte, un webhook de niveau COMPTE est notifié de tous les événements déclenchés dans ce compte.

Le compte de l’utilisateur C a un webhook de niveau GROUPE (créé par l’utilisateur C ou l’administrateur de compte/groupe).

Hypothèse : l’utilisateur A, l’utilisateur C et l’administrateur de groupe se trouvent dans le même groupe.

Oui

Comme l’utilisateur A et l’utilisateur C font partie du même groupe, un webhook de niveau GROUPE est notifié de tous les événements déclenchés dans ce groupe.

Le compte de l’utilisateur C a un webhook de niveau GROUPE (créé par l’utilisateur C ou l’administrateur de compte/groupe).

Hypothèse : les utilisateurs A et C se trouvent dans différents groupes.

Non

Le webhook de niveau GROUPE de l’utilisateur C est considéré comme un webhook non initiateur.

Le webhook de l’utilisateur A (RESSOURCE/UTILISATEUR/GROUPE/COMPTE) sera déclenché.

L’utilisateur C a un webhook de niveau UTILISATEUR .

Non

Le webhook de niveau UTILISATEUR de l’utilisateur C est considéré comme un webhook non initiateur.

Nouvelle tentative lorsque le service d’écoute ne fonctionne pas

Si l’URL cible du webhook ne fonctionne pas pour une raison quelconque, Acrobat Sign met en file d’attente le fichier JSON et tente à nouveau la transmission par cycles progressifs durant 72 heures.

Les événements non distribués sont conservés dans une file d’attente pour de nouvelles tentatives. Au cours des 72 heures à venir, les notifications sont remises dans l’ordre dans lequel elles se sont produites, autant que faire se peut.

La stratégie visant à retenter la remise des notifications consiste à doubler le temps entre les tentatives, depuis 1 minute jusqu’à 12 heures, soit 15 tentatives en l’espace de 72 heures.

Si le récepteur du webhook ne répond pas dans les 72 heures et qu’aucune notification n’a été remise au cours des sept derniers jours, le webhook est désactivé. Aucune notification n’est envoyée à cette URL tant que le webhook n’est pas réactivé.

Toutes les notifications adressées entre le moment où le webhook est désactivé et celui où il est réactivé sont perdues.

Logo Adobe

Accéder à votre compte

Liens rapides

Voir toutes vos formules Gérer vos formules

Informations juridiques    |    Politique de confidentialité en ligne