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
Nouveautés
Commencer
- Guide de démarrage rapide à l’attention des administrateurs
- Guide de démarrage rapide à l’attention des utilisateurs
- Bibliothèque de tutoriels vidéo
- Foire aux questions
Administration
- Présentation d’Admin Console
-
Gestion des utilisateurs
- Ajout d’utilisateurs
- Création d’utilisateurs axés sur les fonctions
- Recherche d’utilisateurs présentant des erreurs d’approvisionnement
- Modification du nom/de l’adresse e-mail
- Modification de l’appartenance d’un utilisateur à un groupe
- Promotion d’un utilisateur à un rôle d’administrateur
- Types d’identités des utilisateurs et SSO
- Changement d’identité d’utilisateur
- Authentification des utilisateurs avec Microsoft Azure
- Authentification des utilisateurs avec la fédération Google
- Profils de produit
- Expérience de connexion
-
Paramètres de compte/groupe
- Présentation des paramètres
-
Paramètres généraux
- Nouvelle expérience pour les destinataires
- Workflows de signature automatique
- Envoi en masse
- Formulaires web
- Workflows Power Automate
- Documents de bibliothèque
- Collecte des données de formulaire avec les accords
- Visibilité limitée de documents
- Ajout d’une copie PDF de l’accord signé en pièce jointe
- Insertion d’un lien dans l’e-mail
- Insertion d’une image dans l’e-mail
- Fichiers joints à un e-mail nommés
- Ajout de rapports d’audit aux documents en pièces jointes
- Fusion de plusieurs documents en un seul
- Téléchargement de documents individuels
- Chargement d’un document signé
- Définition d’un fuseau horaire par défaut
- Utilisateurs dans plusieurs groupes (UMG)
- Autorisations d’administrateur de groupe
- Remplacement du destinataire
- Rapport d’audit
- Pied de page de la transaction
- Client du secteur de la santé
- Configuration du compte
-
Préférences de signature
- Signatures correctement formatées
- Personnalisation des conditions d’utilisation et de la règle concernant la divulgation des informations de l’utilisateur
- Navigation des destinataires dans les champs de formulaire
- Redémarrage du workflow de l’accord
- Refus de signer
- Autorisation des signataires à imprimer et à apposer une signature manuscrite
- Obligation pour les signataires d’utiliser un appareil mobile pour créer leur signature
- Adresse IP des signataires requise
- Signatures numériques
- Cachets électroniques
- Identité numérique
-
Paramètres de rapport
- Paramètres de sécurité
-
Paramètres d’envoi
- Nom du destinataire requis lors de l’envoi
- Verrouillage des valeurs de nom pour les utilisateurs connus
- Rôles autorisés du destinataire
- Autorisation des témoins électroniques
- Groupes de destinataires
- En copie
- Accès du destinataire à l’accord
- Aplatissement du champ
- Modification des accords
- Messages privés
- Types de signature autorisés
- Rappels
- Envoi d’une notification d’accord par
- Options d’identification du signataire
- Protection du contenu
- Ordre de signature
- Liquid Mode
- Paramètres bio-pharma
- Paramètres d’authentification notariale
- Intégration des paiements
- Paramètres SAML
- Gouvernance des données
- Paramètres d’horodatage
- Archive externe
- Langues du compte
-
Paramètres de messagerie
- Images d’en-tête et de pied de page d’e-mail
- Autorisation de pieds de page dans l’e-mail d’un utilisateur individuel
- Personnalisation de l’e-mail « Signature requise »
- Personnalisation des champs « À » et « Cc »
- Activation des notifications sans lien
- Personnalisation des modèles de courrier électronique
- Migration d’echosign.com vers adobesign.com
- Configuration des options pour les destinataires
-
Conseils relatifs aux exigences réglementaires
- Accessibilité
- HIPAA
- RGPD
- 21 CFR Part 11 et EudraLex Annexe 11
- Clients du secteur de la santé
- Prise en charge du service fiscal Income Verification Express Service (IVES)
- Accords « placés dans le coffre »
- Considérations relatives à l’Union européenne et au Royaume-Uni
- Dépôt de votre domaine
- Liens Signaler un abus
Envoi, signature et gestion des accords
-
Options du destinataire
- Annulation d’un rappel par e-mail
-
Options de la page de signature électronique
- Vue d’ensemble de la page de signature électronique
- Ouverture d’un accord pour le lire sans champs
- Refus de signer un accord
- Délégation de l’autorité de signature
- Téléchargement d’un PDF de l’accord
- Affichage de l’historique de l’accord
- Affichage des messages de l’accord
- Conversion d’une signature électronique en signature manuscrite
- Conversion d’une signature manuscrite en signature électronique
- Navigation dans les champs de formulaire
- Effacement des données des champs de formulaire
- Agrandissement de la page de signature électronique et navigation dans la page
- Modification de la langue utilisée dans les outils et informations de l’accord
- Consultation des informations juridiques
- Réglage des préférences d’Acrobat Sign en matière de cookies
- Envoi les accords
-
Création de champs dans des documents
-
Environnement de création intégré à l’application
- Détection automatique des champs
- Glisser-déposer des champs à l’aide de l’environnement de création
- Affectation des champs de formulaire aux destinataires
- Rôle de préremplissage
- Application de champs à l’aide d’un modèle de champ réutilisable
- Transfert de champs vers un nouveau modèle de bibliothèque
- Mise à jour de l’environnement de création lors de l’envoi d’accords
- Création de formulaires avec des balises de texte
- Création de formulaires avec Acrobat (AcroForms)
- Champs
- FAQ sur la création
-
Environnement de création intégré à l’application
- Signature d’accords
-
Gérer les accords
- Présentation de la page Gérer
- Accords de délégation
- Remplacement des destinataires
- Limitation de la visibilité des documents
- Annulation d’un accord
- Création de nouveaux rappels
- Vérification des rappels
- Annulation d’un rappel
- Accès aux flux Power Automate
-
Autres actions
- Fonctionnement de la recherche
- Affichage d’un accord
- Création d’un modèle à partir d’un accord
- Masquage/Affichage des accords dans la vue
- Chargement d’un accord signé
- Modification des fichiers et des champs d’un accord envoyé
- Modification de la méthode d’authentification d’un destinataire
- Ajout ou modification d’une date d’expiration
- Ajout d’une note à l’accord
- Partage d’un accord individuel
- Annulation du partage d’un accord
- Téléchargement d’un accord individuel
- Téléchargement des fichiers individuels d’un accord
- Téléchargement du rapport d’audit d’un accord
- Téléchargement du contenu des fichiers d’un accord
- Rapport d’audit
- Rapports et exportations de données
Fonctionnalités et workflows d’accord avancés
-
Formulaires web
- Création d’un formulaire web
- Modification d’un formulaire web
- Désactivation/Activation d’un formulaire web
- Masquage/Affichage d’un formulaire web
- Recherche de l’URL ou du code de script
- Préremplissage des champs de formulaire web avec les paramètres d’URL
- Enregistrement d’un formulaire web à remplir ultérieurement
- Redimensionnement d’un formulaire web
-
Modèles réutilisables
- Formulaires de l’administration américaine dans la bibliothèque Acrobat Sign
- Création d’un modèle de bibliothèque
- Modification du nom d’un modèle de bibliothèque
- Modification du type d’un modèle de bibliothèque
- Modification du niveau d’autorisation d’un modèle de bibliothèque
- Copie, modification et enregistrement d’un modèle partagé
- Téléchargement des données de champ agrégées d’un modèle de bibliothèque
- Transfert de la propriété des formulaires web et des modèles de bibliothèque
-
Workflows Power Automate
- Présentation de l’intégration Power Automate et des droits inclus
- Activation de l’intégration Power Automate
- Actions contextuelles sur la page Gérer
- Suivi de l’utilisation de Power Automate
- Création d’un flux (exemples)
- Déclencheurs utilisés pour les flux
- Importation de flux depuis l’extérieur d’Acrobat Sign
- Gestion des flux
- Modification des flux
- Partage des flux
- Désactivation ou activation des flux
- Suppression des flux
-
Modèles utiles
-
Administrateur uniquement
- Enregistrement de tous les documents terminés dans SharePoint
- Enregistrement de tous les documents terminés dans OneDrive Entreprise
- Enregistrement de tous les documents terminés dans Google Drive
- Enregistrement de tous les documents terminés dans Dropbox
- Enregistrement de tous les documents terminés dans Box
- Archivage des accords
- Archivage des accords de formulaire web
- Extraction des données d’accord
- Notifications d’accord
- Génération d’un accord
-
Administrateur uniquement
- Workflows d’envoi personnalisés
- Partage d’utilisateurs et d’accords
Intégration à d’autres produits
- Acrobat Sign pour Saleforce
- Acrobat Sign pour Microsoft
- Autres intégrations
- Intégrations gérées par des partenaires
- Obtention d’une clé d’intégration
Développeur Acrobat Sign
Assistance et dépannage
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.
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.
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.
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.
Limitation de taux basée sur la simultanéité
Les événements de création et de notification de webhook (et de rappel) sont limités au nombre de notifications simultanées qui sont activement envoyées au client à partir du système Acrobat Sign. Cette limite s’applique au compte, pour inclure tous les groupes qu’il contient.
Ce type de limitation de taux empêche un compte mal conçu de consommer une quantité disproportionnée de ressources serveur, ce qui aurait un impact négatif sur tous les autres clients de cet environnement de serveur.
Le nombre d’événements simultanés par compte a été calculé pour que les comptes dont les webhooks sont bien configurés reçoivent leurs notifications dans le plus court délai possible et qu’il soit rare que les notifications soient retardées en raison d’un trop grand nombre de demandes. Voici les seuils actuels :
Action |
Nombre maximal |
Description |
Création de webhook |
10 |
10 demandes de création de webhook simultanées au plus sont autorisées par compte. |
Notification de webhook/rappel |
30 |
30 notifications simultanées de webhook et de rappel au plus sont autorisées par compte. |
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.
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.
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 ?