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
- Installation du package
- Configuration du package
- Guide de l’utilisateur
- Activation de l’authentification par identité numérique
- Guide du développeur
- Guide de personnalisation avancée
- Guide de mappage de champs et modèles
- Guide d’utilisation de l’application mobile
- Guide d’automatisation des flux
- Guide de Document Builder
- Configuration de documents volumineux
- Guide de mise à niveau
- Notes de mise à jour
- Forum aux questions
- Guide de dépannage
- Articles supplémentaires
- Acrobat Sign pour Microsoft 365
- Acrobat Sign pour Outlook
- Acrobat Sign pour Word/PowerPoint
- Acrobat Sign pour Teams
- Acrobat Sign pour Microsoft PowerApps et Power Automate
- Connecteur Acrobat Sign pour Microsoft Search
- Acrobat Sign pour Microsoft Dynamics
-
Acrobat Sign pour Microsoft SharePoint
- Présentation
- SharePoint sur site : guide d’installation
- SharePoint sur site : guide de mappage de modèles
- SharePoint sur site : guide de l’utilisateur
- SharePoint sur site : notes de mise à jour
- SharePoint en ligne : guide d’installation
- SharePoint en ligne : guide de mappage de modèles
- SharePoint en ligne : guide de l’utilisateur
- SharePoint en ligne : guide de mappage de formulaires web
- SharePoint en ligne : notes de mise à jour
- Intégrations d’Adobe Acrobat Sign
- Versions de produit et cycle de vie
-
Acrobat Sign pour Saleforce
- Installation du package
- Configuration du package
- Guide de l’utilisateur
- Activation de l’authentification par identité numérique
- Guide du développeur
- Guide de personnalisation avancée
- Guide de mappage de champs et modèles
- Guide d’utilisation de l’application mobile
- Guide d’automatisation des flux
- Guide de Document Builder
- Configuration de documents volumineux
- Guide de mise à niveau
- Notes de mise à jour
- Forum aux questions
- Guide de dépannage
- Articles supplémentaires
-
Acrobat Sign pour Microsoft
- Acrobat Sign pour Microsoft 365
- Acrobat Sign pour Outlook
- Acrobat Sign pour Word/PowerPoint
- Acrobat Sign pour Teams
- Acrobat Sign pour Microsoft PowerApps et Power Automate
- Connecteur Acrobat Sign pour Microsoft Search
- Acrobat Sign pour Microsoft Dynamics
-
Acrobat Sign pour Microsoft SharePoint
- Présentation
- SharePoint sur site : guide d’installation
- SharePoint sur site : guide de mappage de modèles
- SharePoint sur site : guide de l’utilisateur
- SharePoint sur site : notes de mise à jour
- SharePoint en ligne : guide d’installation
- SharePoint en ligne : guide de mappage de modèles
- SharePoint en ligne : guide de l’utilisateur
- SharePoint en ligne : guide de mappage de formulaires web
- SharePoint en ligne : notes de mise à jour
- Acrobat Sign pour ServiceNow
- Acrobat Sign pour les RH ServiceNow
- Acrobat Sign pour SAP SuccessFactors
- Acrobat Sign pour Workday
- Acrobat Sign pour NetSuite
- Acrobat Sign pour SugarCRM
- Acrobat Sign pour VeevaVault
- Acrobat Sign pour Coupa BSM Suite
- Acrobat Sign pour Zapier
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.
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.
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 :
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.
Options de configuration
La configuration du webhook nécessite la définition de cinq éléments :
- Nom : il est conseillé d’utiliser un nom intuitif que les autres administrateurs peuvent facilement comprendre.
- Portée : envergure du webhook. Le compte et le groupe sont disponibles dans l’interface.
- L’API prend en charge les portées Compte, Groupe, Utilisateur et Ressource.
- Une seule portée par webhook peut être définie.
- URL : URL cible à laquelle Acrobat Sign a envoyé la payload JSON.
- Événements : déclencheur qui provoque la création du fichier JSON par Acrobat Sign et son envoi à l’URL.
- Chaque événement génère une payload différente en fonction de l’événement de déclenchement.
- Plusieurs événements peuvent être inclus dans un webhook.
- Paramètres de notification : les Paramètres de notification identifient les sections de la payload JSON Événement, ce qui vous permet de sélectionner uniquement les sections de l’événement qui sont importantes pour ce webhook (et donc de réduire les données inutiles dans votre URL).
Une fois le webhook défini, cliquez sur Enregistrer. Le nouveau webhook commence à réagir pour déclencher immédiatement des événements.
Configurez l’URL du webhook pour répondre aux demandes de vérification et de notification de webhook conformément au protocole de vérification expliqué ci-dessus. ID client (ID d’application) qui est envoyé aux webhooks créés à partir de l’application web Acrobat Sign : UB7E5BXCXY.
Portées
- Compte : tous les événements souscrits survenant dans le compte déclenchent l’envoi.
- Les administrateurs de compte sont autorisés à afficher tous les webhooks définis pour le compte et tous les groupes de ce compte.
- Groupe : tous les événements souscrits survenant dans le groupe déclenchent l’envoi. REMARQUE : les webhooks de portée de groupe existent uniquement pour ce groupe.
- Les administrateurs de groupe voient uniquement les webhooks dédiés à leur groupe. Ils ne peuvent pas voir les webhooks au niveau du compte ni ceux qui sont liés à d’autres groupes.
- Les comptes pour lesquels la fonctionnalité Utilisateurs dans plusieurs groupes est activée voient l’option permettant de définir le groupe auquel la portée doit être appliquée.
- Compte utilisateur : tous les événements souscrits pour un compte utilisateur déclenchent l’envoi. Les webhooks au niveau de l’utilisateur peuvent uniquement être créés via une API.
- Webhook de niveau ressource : il est créé pour une ressource spécifique. Les événements propres à cette ressource sont envoyés vers l’URL du webhook. Les webhooks de niveau ressource peuvent uniquement être créés via une API.
URL
Une URL de webhook est un serveur qui écoute les messages de notification HTTPS POST entrants qui sont déclenchés lorsque des événements se produisent.
Vous avez besoin de cette URL pour abonner votre webhook aux événements.
- Le client doit inclure une URL HTTPS à laquelle Acrobat Sign peut envoyer une requête POST. Cette URL doit être disponible sur l’Internet public.
- Par exemple, les URI 127.0.0.1 et localhost ne fonctionnent pas.
- Le point de terminaison de l’URL doit être à l’écoute sur le port 443 ou 8443 (décidé par le client lors de la définition de l’URL de rappel).
- Assurez-vous que le webhook prend en charge les requêtes POST pour les notifications d’événements entrants et les requêtes GET pour la demande de vérification.
- L’URL ne doit pas être bloquée par un pare-feu.
Vous trouverez ci-dessous les événements qui peuvent déclencher une transmission de type push vers l’URL du webhook, regroupés par objet et répertoriés dans l’ordre trouvé dans l’interface utilisateur.
La valeur située à gauche correspond à celle qui apparaît dans l’interface utilisateur d’Acrobat Sign. La valeur située à droite correspond au nom du webhook dans l’API.
Pour en savoir plus sur les webhooks et leurs payloads, consultez le Guide pour les développeurs Acrobat Sign.
Accords :
Élément de l’interface utilisateur | Nom du webhook |
Tous les événements liés à l’accord | AGREEMENT_ALL |
Accord créé | AGREEMENT_CREATED |
Accord envoyé | AGREEMENT_ACTION_REQUESTED |
Participant à l’accord terminé | AGREEMENT_ACTION_COMPLETED |
Flux de l’accord terminé | AGREEMENT_WORKFLOW_COMPLETED |
Accord expiré | AGREEMENT_EXPIRED |
Accord supprimé | AGREEMENT_DOCUMENTS_DELETED |
Accord annulé | AGREEMENT_RECALLED |
Accord refusé | AGREEMENT_REJECTED |
Accord partagé | AGREEMENT_SHARED |
Accord délégué | AGREEMENT_ACTION_DELEGATED |
Participant à l’accord modifié | AGREEMENT_ACTION_REPLACED_SIGNER |
Accord modifié | AGREEMENT_MODIFIED |
Modification de l’accord réceptionnée | AGREEMENT_USER_ACK_AGREEMENT_MODIFIED |
Courrier électronique de l’accord consulté | AGREEMENT_EMAIL_VIEWED |
Courrier électronique de l’accord non remis | AGREEMENT_EMAIL_BOUNCED |
Échec de la création de l’accord | AGREEMENT_AUTO_CANCELLED_CONVERSION_PROBLEM |
Accord synchronisé après l’événement hors ligne | AGREEMENT_OFFLINE_SYNC |
Accord téléchargé par l’expéditeur | AGREEMENT_UPLOADED_BY_SENDER |
Accord sécurisé | AGREEMENT_VAULTED |
Identité sociale du participant à l’accord authentifiée | AGREEMENT_WEB_IDENTITY_AUTHENTICATED |
Authentification du participant à l’accord fondée sur les connaissances | AGREEMENT_KBA_AUTHENTICATED |
Rappel d’accord envoyé | AGREEMENT_REMINDER_SENT |
Nom du signataire de l’accord modifié par le signataire | AGREEMENT_SIGNER_NAME_CHANGED_BY_SIGNER |
Webhooks d’accord uniquement disponibles via l’API | |
s.o. | AGREEMENT_EXPIRATION_UPDATED |
s.o. |
AGREEMENT_READY_TO_NOTARIZE |
s.o. |
AGREEMENT_READY_TO_VAULT |
Envoi en masse :
Élément de l’interface utilisateur | Nom du webhook |
Envoi en masse - Tous les événements | MEGASIGN_ALL |
Envoi en masse - Créé |
MEGASIGN_CREATED |
Envoi en masse - Partagé |
MEGASIGN_SHARED |
Envoi en masse - Rappelé |
MEGASIGN_RECALLED |
Formulaires web :
Élément de l’interface utilisateur | Nom du webhook |
Formulaire web - Tous les événements | WIDGET_ALL |
Formulaire web créé |
WIDGET_CREATED |
Formulaire web activé |
WIDGET_ENABLED |
Formulaire web désactivé |
WIDGET_DISABLED |
Formulaire web modifié |
WIDGET_MODIFIED |
Formulaire web partagé |
WIDGET_SHARED |
Échec de création du formulaire web |
WIDGET_AUTO_CANCELLED_CONVERSION_PROBLEM |
Modèles de bibliothèque (API uniquement) :
Élément de l’interface utilisateur | Nom du webhook |
s.o. | LIBRARY_DOCUMENT_ALL |
s.o. | LIBRARY_DOCUMENT_CREATED |
s.o. | LIBRARY_DOCUMENT_AUTO_CANCELLED_CONVERSION_PROBLEM |
s.o. | LIBRARY_DOCUMENT_MODIFIED |
Paramètres de notification
Les paramètres de notification vous permettent de personnaliser la payload JSON en fonction d’éléments spécifiques de l’événement.
Par exemple, dans un événement Participant à l’accord modifié, il se peut que vous ne souhaitiez que les Informations sur l’accord et les Informations sur les participants, sans les Informations sur les documents, afin de réduire la taille totale du fichier JSON envoyé à l’URL du webhook.
- Accord
- Informations sur l’accord : informations détaillées sur l’accord, basées sur l’état de celui-ci au moment du déclenchement de l’événement.
- Infos sur les documents de l’accord : inclut toutes les informations sur les documents générés suite à l’événement.
- Infos sur les participants à l’accord : inclut toutes les informations sur les participants à la suite de l’événement.
- Document signé de l’accord : fournit le PDF signé.
- Applicable à Flux de l’accord terminé et Tous les événements liés à l’accord.
- Envoyer en masse
- Infos Envoyer en masse : informations détaillées sur l’objet Envoyer en masse qui a déclenché l’événement.
- Formulaire web
- Informations sur le widget : informations détaillées sur le formulaire web qui a déclenché l’événement.
- Informations sur les documents du widget : informations sur les documents associées au formulaire web.
- Informations sur les participants au widget : informations sur les participants définis dans le formulaire web.
Authentification SSL bidirectionnelle
Le protocole SSL bidirectionnel, souvent appelé SSL côté client ou TLS mutuel, est un mode de protocole SSL dans lequel le serveur et le client (navigateur web) présentent tous deux des certificats pour s’identifier.
Les administrateurs de compte peuvent configurer un certificat côté client dans la page Paramètres de sécurité.
Acrobat Sign vérifie les certificats SSL lors de la remise des payloads à l’URL du webhook. Les webhooks qui échouent à la vérification des certificats SSL ne remettent pas correctement la payload JSON.
Utilisez le protocole SSL bidirectionnel pour authentifier le client (Acrobat Sign) et le service d’écoute afin de vous assurer que seul Acrobat Sign peut accéder à l’URL du webhook.
Si le webhook a été créé par une application partenaire, il utilise un certificat client (le cas échéant) du compte de l’application partenaire pour s’identifier lors des envois de notifications du webhook.
Vous trouverez ci-dessous les questions les plus courantes concernant le processus de vérification du serveur web et la vérification de la certification du client.
Vérification du serveur web
Lors de l’enregistrement d’un webhook, Acrobat Sign vérifie l’URL du serveur webhook.
Les clients ne peuvent pas enregistrer le webhook si la connexion à l’URL de rappel du webhook ne peut pas être établie à partir d’Acrobat Sign.
Vérification du certificat client
Activation et désactivation
L’accès à la fonctionnalité Webhooks est activé par défaut pour les comptes de formule Entreprise.
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 : Compte > Webhooks.
Activation d’un webhook
Lorsqu’un webhook est créé pour la première fois, il est défini sur le statut Actif.
La page Webhooks d’Acrobat Sign affiche les webhooks actifs par défaut.
Pour activer un webhook inactif :
- Cliquez sur l’icône Options (trois lignes horizontales) à droite de la ligne d’en-tête des webhooks et sélectionnez Afficher tous les webhooks.
- Cliquez sur le webhook inactif pour le sélectionner.
- Les options du webhook s’affichent juste au-dessous de la ligne d’en-tête.
- Cliquez sur Activer.
Le webhook actif commence à envoyer des données à l’URL cible dès que l’événement suivant est déclenché.
Désactivation d’un webhook
Pour désactiver un webhook, vous devez effectuer les actions suivantes :
- Accéder à la page Webhooks.
- Cliquer sur le webhook que vous souhaitez désactiver.
- Sélectionner Désactiver dans les éléments de menu sous la ligne d’en-tête.
- Une fois désactivé, le webhook affiche le statut Inactif.
Affichage ou modification d’un webhook
Les webhooks peuvent être modifiés et enregistrés à tout moment. Dès que vous enregistrez une nouvelle configuration, cette modification prend effet immédiatement.
Seuls Événements et Paramètres de notification peuvent être modifiés.
Si les paramètres Nom, Portée ou URL doivent être modifiés, vous devez créer un nouveau webhook.
Pour modifier les paramètres d’un webhook :
- Accédez à la page Webhooks.
- Cliquez sur le webhook que vous souhaitez modifier.
- Cliquez sur l’option Afficher/Modifier sous la ligne d’en-tête.
- Appliquez les modifications nécessaires, puis cliquez sur Enregistrer.
Suppression d’un webhook
Vous pouvez supprimer un webhook à tout moment.
La suppression d’un webhook entraîne sa destruction du système. Il n’est donc pas possible de récupérer un webhook supprimé.
Les webhooks n’ont pas besoin d’être désactivés en premier lieu.
Pour supprimer un webhook :
- Accédez à Webhooks.
- Cliquez sur le webhook que vous souhaitez supprimer.
- Cliquez sur l’option Supprimer sous la ligne d’en-tête.
- Un message s’affiche pour vérifier que vous souhaitez bien supprimer le webhook. Cliquez sur OK.
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.
Dans ce cas, l’objet « ConditionalParametersTrimmed » est retourné dans la réponse, 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 remettent des notifications qui s’appliquent à tous les participants d’un accord si un webhook est configuré pour cet utilisateur, son groupe ou son compte.
Les événements d’accord sont traités de telle sorte que si un webhook est configuré pour le participant applicable de cet événement, une notification est envoyée à l’URL de ce webhook. En d’autres termes, les webhooks sont déclenchés pour les événements dans tous les accords applicables, même ceux en dehors du groupe ou du compte dans lequel le webhook est configuré.
Les notifications sont envoyées uniquement pour les événements auxquels le participant est associé. Par exemple, l’expéditeur d’un accord reçoit presque toutes les notifications, alors que les destinataires n’en reçoivent qu’à partir du début de leur participation à l’accord, et uniquement pour les événements dans lesquels ils sont impliqués.
Les notifications du webhook suivent le modèle d’authentification et de visibilité actuel d’Acrobat Sign. Les utilisateurs n’ont donc accès à l’accord que lorsque leur participation à un accord commence.
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.
Recevez de l’aide plus rapidement et plus facilement
Nouvel utilisateur ?