Foire aux questions à l’attention des développeurs DocuSign – Modèles, enveloppes et Connect

Foire aux questions à l’attention des développeurs DocuSign – Modèles, gestion des enveloppes et Connect

Vous trouverez ci-dessous des réponses à quelques-unes des questions les plus fréquentes concernant les modèles, la gestion des enveloppes et Connect. Si vous voulez consultez des foires aux questions destinées aux développeurs sur d’autres rubriques, reportez-vous à Foire aux questions à l’attention des développeurs DocuSign – Table des matières ou utilisez les liens se trouvant sous Références à la fin de cette page.


Modèles


Gestion des enveloppes


Connect


Modèles

Les modèles aident à rationaliser le processus d’envoi lorsque vous envoyez fréquemment des documents identiques ou similaires, ou envoyez des documents au même groupe de personnes.


Pourquoi les rôles de mes modèles ne correspondent-ils pas ?

Pour que les rôles de vos modèles correspondent, les valeurs que vous fournissez pour vos paramètres routingOrder et roleName doivent être identiques au rôle que vous faites correspondre.


Quels sont certains comportements et problèmes possibles lors de la mise en correspondance de modèles ?

Scénario : même rôle, nom différent

Résultats :

  1. L’erreur d’API ONESIGN_ALLSIGN_NOTSATISFIED est renvoyée si la visibilité de document est activée sur un compte DS.
  2. Si la visibilité de document n’est pas activée dans le compte, l’enveloppe sera envoyée avec les destinataires en double au même e-mail. L’une a des onglets, l’autre non.

Scénario : rôle différent, même nom ou e-mail

Résultats :

Erreur : l’enveloppe contient des destinataires en double. Cela crée un nouveau destinataire avec le même nom, la même adresse e-mail et la même position dans l’ordre de signature que le destinataire d’origine. Cela se traduit souvent par une erreur indiquant que l’enveloppe contient des destinataires en double. Dans cette situation, les utilisateurs finaux peuvent voir une erreur lorsqu’ils travaillent avec des onglets indiquant que les champs ne sont pas synchronisés.

 


Comment créer et préremplir sur un modèle des valeurs de balises ?

Pour fournir une valeur pour un onglet sur un modèle, vous pouvez fournir la valeur à côté de l’étiquette de l’onglet dans vos définitions d’onglets. Consultez notre exemple pour définir les valeurs d’onglet de modèle.


Gestion des enveloppes

La gestion des enveloppes vous permet de créer, envoyer, repérer, suivre et gérer les enveloppes dans votre compte.


L’API eSignature REST peut-elle remplacer les rappels et les expirations par défaut du compte ?

Oui. Lorsque vous créez une enveloppe avec l’API, vous pouvez définir le nombre de jours après envoi pour rappeler les destinataires et à quelle fréquence. Vous pouvez aussi définir la date d’expiration de l’enveloppe et le nombre de jours avant expiration pour avertir le destinataire. Vous pouvez trouver sur le blog DocuSign une explication détaillée et des exemples de code en plusieurs langues sur l’utilisation de nos SDK.


Comment puis-je éviter que mon application soit limitée par les limites applicables au taux d’API DocuSign ?

DocuSign a des limites de débit par défaut de 1000 appels API par heure, des limites API en rafale de 500 appels en 30 secondes, et des règles d’interrogation indiquant que les appels GET vers la même ressource d’enveloppe ne peuvent pas être passés plus d’une fois toutes les 15 minutes.

Vous pouvez éviter les limites de débit en vérifiant votre utilisation de l’API, en utilisant des opérations en masse et en évitant de demander plusieurs fois des informations sur les enveloppes à l’état terminal (Complétée, Invalidée, Refusée). Au lieu d’interroger, nous vous recommandons d’utiliser des webhooks via DocuSign Connect. Vous n’avez pas besoin de changer votre pare-feu pour utiliser les notifications webhook ; consultez notre article de blog.

Vous pouvez trouver sur notre blog une discussion détaillée sur les limites de débit API et comment travailler plus efficacement et des conseils sur les limites générales des ressources API sur le Centre développeur.


Pourquoi les chaînes d’ancrage ne sont-elles pas appliquées si nous utilisons la méthode UpdateDocumentsAsync ?

Le traitement des étiquettes d’ancrage ne se produit pas lorsque des documents supplémentaires sont ajoutés à l’enveloppe. Vous devrez soit inclure tous les documents dans l’appel de création d’enveloppe initial, soit effectuer un appel Envelopes::UpdateRecipients avec les étiquettes souhaitées une fois que tous les documents ont été appliqués à l’enveloppe. Si vous utilisez la méthode UpdateRecipient (Mettre à jour le destinataire) pour ajouter des étiquettes, il est recommandé qu’aucune balise ne soit définie dans l’appel de création d’enveloppe initial pour empêcher la duplication des étiquettes par la suite dans le workflow.


Comment passer un « destinataire signataire » en « copie carbone » ?

Pour cette tâche, la méthode Envelopes::UpdateRecipients doit être utilisée. Pour le corps de l’appel, vous devez définir un destinataire « Copie carbone » avec l’Identifiant du destinataire du signataire que vous souhaitez changer en CC. Aucun autre paramètre ne doit être modifié, cela pourrait d’ailleurs entraîner l’échec de la modification. Si l’Identifiant du destinataire du troisième destinataire sur une enveloppe est « 3 », l’appel pour le changer en destinataire « Copie carbone » serait un PUT vers {{vx}}/accounts/{{account_id}}/envelopes/{{envelope_id}}/recipients avec un corps

 

{
  ’carbonCopies’: [
    {
      ’recipientId’: ’3’
    }
  ]
}

Notez que la méthode UpdateRecipients (Mettre à jour les destinataires) renverra une réponse « 200 OK », que la modification ait réellement pris effet ou non. Pour confirmer que la mise à jour a réussi, votre application devra analyser le corps de la réponse pour rechercher un état de succès ou d’échec :

{
  ’recipientUpdateResults’: [
    {
      ’recipientId’: ’3’
      ’errorDetails’: {
        ’errorCode’: ’SUCCESS’,
        Message
      }
    }
  ]
}

Remarque : Le rôle du destinataire ne peut pas être modifié sur des enveloppes complétées.


Quelles sont les limites de taille de fichier pour les enveloppes ?

Un article public décrivant les limitations de taille des fichiers d’enveloppe est disponible ici : https://support.docusign.com/fr/articles/DocuSign-Document-and-Envelope-File-Size-Limitations

Paquets de documents individuels (ou téléchargements de documents individuels) :

Ils sont limités à 25 Mo par paquet, selon l’interface que vous utilisez. Cette limite est appliquée au niveau de la plateforme.

 


Comment activer la signature adaptative ?

Lorsque vous essayez d’utiliser les fonctionnalités de signature adaptative, l’une des erreurs suivantes peut s’afficher :

  • PLAN_ITEM_NOT_ENABLED
  • SMARTSECTIONS_NOT_ENABLED

La signature adaptative est actuellement activée pour tous les nouveaux comptes Developer Sandbox. Si les erreurs susmentionnées s’affichent, vous devrez contacter le Centre d’assistance de DocuSign afin d’activer deux fonctionnalités :

  • Autoriser les destinataires à signer des documents de manière adaptative
  • SmartSections/API pour la signature adaptative activées

S’il s’agit d’un compte de Production, veuillez plutôt visiter notre page Contacter l’assistance et créer une requête pour discuter de l’activation de ces fonctionnalités.


Comment contrôler les tampons des identifiants d’enveloppe avec l’API ?

Pour placer une étiquette qui affiche l’Identifiant d’enveloppe à un emplacement spécifique :

{
    ’envelopeIdTabs’: 
                           {
                               "tabLabel":  "EIDStamp",
                               "conditionalParentLabel":  null,
                               "conditionalParentValue":  null,
                               "fontSize":  "size9",
                               "underline":  faux,
                               "italic":  faux,
                               "fontColor":  "black",
                               "bold":  faux,
                               "font":  "lucidaconsole",
                               ’pageNumber’: ’1’, 
                               ’documentId’: ’1’, 
                               ’recipientId’: ’86887495’ 
                               "height":  14,
                               "width":  66,
                               "xPosition":  106,
                               "yPosition":  235
                           }
                       ]
}

Il existe également deux paramètres au niveau du compte qui peuvent être modifiés en effectuant un PUT vers accounts/accountId/settings

{
    ’accountSettings’: 
                            {
                                "name":  "enableEnvelopeStampingByAccountAdmin",
                                "value":  "true"
                            },

                            {
                                "name":  "envelopeStampingDefaultValue",
                                "value":  "false"
                            }
                        ]
}

Enfin, il existe une troisième option pour ajouter/supprimer le tampon d’identification d’enveloppe lors des appels de création d’enveloppe ou de création de modèle. Elle apparaît dans les définitions d’enveloppe aux côtés d’emailBlurb et d’emailSubject.

     "envelopeIdStamping":"true"

Comment vérifier le statut des enveloppes par le biais de mon application ?

En général, DocuSign décourage de lancer une interrogation pour vérifier activement les mises à jour de l’état des enveloppes. Cela dit, si DocuSign Connect ne peut pas être utilisé pour surveiller l’état des enveloppes, lancer une interrogation sur l’état peut être une solution de secours viable. La méthode Envelopes::ListStatus peut être utilisée pour lancer une interrogation sur plusieurs enveloppes à la fois. En regroupant ces demandes sur l’état, une intégration peut réduire le volume de trafic d’API dédié à l’interrogation.

Lancer une interrogation sur l’état d’une enveloppe ne doit pas se produire plus d’une fois toutes les quinze minutes (conformément aux limites en ressources de l’API), mais pour les enveloppes plus anciennes, il est souvent inutile de lancer une interrogation aussi fréquemment. À mesure qu’une enveloppe prend de l’âge, il peut être approprié de réduire le nombre d’interrogations à une fois par heure ou même par jour. La définition d’un délai d’expiration approprié pour les enveloppes peut empêcher les enveloppes anciennes de consommer du trafic API.


Pourquoi mon appel API qui fait référence à un modèle aboutit-il à un destinataire sans balises ? Comment résoudre l’erreur « ONESIGNALLSIGN_NOT_SATISFIED – la signature sous forme libre n’est pas autorisée » lorsque j’ai placé des balises de modèle pour le destinataire ?

Ceci est généralement le résultat d’une incompatibilité entre les rôles sur le modèle de serveur et les rôles définis dans l’appel d’API. Pour diagnostiquer le problème, il est utile de capturer un journal d’API pour savoir exactement ce qui est envoyé à DocuSign. Erreurs courantes :

  • Espace à la fin dans le nom du rôle.
  • Le nom du rôle doit être identique à celui du mappage.
  • Incohérence dans l’ordre d’acheminent défini dans l’appel API et sur le modèle de serveur.
  • Si un ordre d’acheminement personnalisé doit être défini dans l’appel API, le paramètre de chaîne de requête « change_routing_order=true » doit être défini. Sinon, supprimez le paramètre RoutingOrder (ordre d’acheminement) de l’appel API.
  • Si un ordre d’acheminement n’est pas défini sur le modèle, tous les destinataires auront un ordre d’acheminement de « 1 ».
  • Le modèle de serveur a un nom de destinataire et une adresse e-mail prédéfinis.
  • Un appel API référençant un modèle ne peut pas remplacer un destinataire prédéfini. Si l’appel API doit définir le nom et l’adresse e-mail du destinataire, le modèle de serveur doit laisser le nom et l’adresse e-mail du destinataire vides afin qu’ils puissent être utilisés comme espaces réservés.
  • Enfin, il peut être utile d’ouvrir l’enveloppe pour la corriger afin de confirmer si les étiquettes sont présentes et attribuées au bon destinataire. Si des étiquettes apparaissent lorsque l’enveloppe est Corrigée, mais pas lorsque le signataire accède à la session de signature, essayez de demander une session de signature captive pour un destinataire distant ou d’accéder à l’enveloppe en tant que mauvais destinataire – la vérification de l’historique de l’enveloppe montrera qui a vu l’enveloppe à un moment donné.

Comment définir les destinataires témoins à l’aide de l’API eSignature ?

DocuSign eSignature offre la possibilité d’attester une signature par témoins. En utilisant l’API REST eSignature, le signataire doit disposer de l’attribut « signWithWitness » : true. L’API peut également suggérer des noms et des adresses e-mail pour le(s) témoin(s). Vous trouverez ci-dessous un corps JSON qui envoie une enveloppe avec un signataire qui nécessite un témoin et suggère un nom et une adresse e-mail pour ce témoin.

{
    Documents
        {
            "documentBase64": "BASE_64_OMITTED",
            "documentId": "1",
            "fileExtension": "pdf",
            "name": "Test.pdf"
        }
    ],
    "emailSubject": "Witness Example",
    "recipients": {
        "signers": [
            {
                "email": "gxxxx@company.com",
                "name": "Geoff Tester",
                "signWithWitness": true,
                "recipientId": "1",
                "requireIdLookup": "false",
                "routingOrder": "1",
                "tabs": {
                    "signHereTabs": [
                        {
                            "documentId": "1",
                            "pageNumber": "1",
                            "recipientId": "1",
                            "xPosition": "100",
                            "yPosition": "150"
                        }
                    ],
                }
            }
        ],
            "witnesses": [
        {
            "name": "Jane",
            "email": "janexxxxx@company.com",
            "roleName": "Witness 1 for Geoff",
            "note": "",
            "routingOrder": 1,
            "status": "created",
            "templateAccessCodeRequired": null,
            "deliveryMethod": "email",
            "witnessFor": "1",
            "recipientId": "2",
                "tabs": {
                    "signHereTabs": [
                        {
                            "documentId": "1",
                            "pageNumber": "1",
                            "recipientId": "1",
                            "xPosition": "200",
                            "yPosition": "150"
                        }
                    ]
                }
        }
        ]
    },
    "status": "sent"
}

    Comment puis-je récupérer un historique d’enveloppe détaillé ou une traçabilité détaillée à l’aide de l’API REST eSignature ?

    Utilisez le point de fin listAuditEvents pour que tous les événements d’une enveloppe soient renvoyés en tant qu’ensemble d’événements, chaque événement étant constitué d’un ensemble de paires nom/valeur. Nous vous conseillons de pratiquer cet appel sur diverses enveloppes test et d’examiner les réponses afin de déterminer les événements que vous voulez récupérer pour votre application.


    Comment empêcher les destinataires de réattribuer des enveloppes par le biais de l’API REST eSignature ?

    Définissez la propriété d’enveloppe « allowReassign » sur « false » dans l’objet envelopeDefinition de votre requête Créer enveloppe.


    Pourquoi l’e-mail de réalisation ne présente-t-il pas le document signé lorsque les enveloppes sont créées à l’aide de l’API REST eSignature ?

    Pour configurer ce paramètre, ouvrez l’application web DocuSign eSignature et allez à Paramètres > Paramètres de l’Espace Signer > Remise d’enveloppe, puis cochez la case Joindre les documents à l’e-mail de réalisation.

    Vous devez être administrateur pour pouvoir gérer ces paramètres.

    Lorsque cette option est sélectionnée, tous les documents complétés sont inclus dans l’e‑mail qui est envoyé aux expéditeurs et aux signataires sous forme de fichiers PDF joints.

    Si vous avez vérifié que le compte est correctement configuré, et que les documents ne sont pas joints à l’e-mail de réalisation, le problème peut être dû à autre chose. Référez-vous à cet article pour les raisons possibles et les solutions.


    Pourquoi les sauts de ligne dans les documents HTML ne sont-ils pas respectés sur le document PDF complété ?

    Les documents HTML qui sont chargés via l’application web eSignature ou l’API à l’aide de la propriété de document standard prennent en charge la définition des sauts de ligne avec le CSS en ligne suivant :

     

    Les documents HTML adaptatifs chargés via l’API ne prennent pas en charge les sauts de page. Les documents adaptatifs ont été conçus pour s’afficher correctement sur n’importe quel appareil, quelle que soit la taille.

    Si vous désirez une nouvelle page sur l’ensemble des appareils, vous pouvez charger des documents html distincts ; une fois ceux-ci convertis en PDF, ils s’afficheront en tant que pages séparées.


    Comment envoyer une enveloppe au nom d’un autre utilisateur ?

    DocuSign prend en charge differents types d’OAuth. Même si chaque type d’OAuth fonctionne légèrement différemment, les configurations suivantes prennent en charge la fonctionnalité d’envoi de la part de quelqu’un :

    Les octrois de code d’autorisation sont idéaux pour les ISV, car la personne de la part de qui l’envoi est réalisé doit être présente et saisir ses informations d’identification.

    Les jetons web JSON ne nécessitent pas la présence d’un utilisateur, mais il faut que la personne de la part de qui l’envoi est réalisé vous autorise à le faire. Une fois son autorisation obtenue, vous pouvez générer de nouveaux jetons OAuth de la part de l’utilisateur concerné. Lorsque vous utiliserez ce jeton pour envoyer une enveloppe, vous serez authentifié comme l’utilisateur concerné et enverrez l’enveloppe en son nom. Reportez-vous aux articles suivants pour plus d’informations :

    Attribution d’un code d’autorisation

    OAuth JWT : accorder le consentement

     


    Comment créer des boutons radio à l’aide de l’API ?

    Pour placer des onglets Groupe de boutons radio via un appel API, il existe deux sections : les définitions d’onglets Groupe de boutons radio et les boutons Groupe de boutons radio.

    Les définitions de groupes de boutons radio incluent l’identifiant du document et celui du destinataire, le nom du groupe de boutons radio, et si le groupe est requis ou non.

    Les boutons eux-mêmes sont ajoutés de façon individuelle à l’éventail des boutons du groupe de boutons radio. Les définitions pour chaque bouton doivent contenir une chaîne d’ancrage ou un numéro de page, une xPosition et une yPosition. Vous pouvez également fournir des paramètres complémentaires tels que la taille de la police, la couleur de la police et les effets d’italique et de mise en gras.

    Définition des groupes de boutons radio et onglets :

    	Onglets Groupe de boutons radio :
    		Identifiant du document
    		ID du destinataire
    		Nom du groupe
    		partagé
    		requiredInitialOnSharedChange
    		requireAll
    		Infobulle
    		tabType (radiogroup)
    		Boutons Groupe de boutons radio >
    			Bouton 1>
    				PageNumber
    				xPosition
    				yPosition
    				valeur
    				sélectionnée (vrai/faux)
    				verrouillé
    				tabOrder
    			Bouton 2>
    				PageNumber
    				xPosition
    				yPosition
    				valeur
    				sélectionnée (vrai/faux)
    				verrouillé
    				tabOrder
    			Bouton 3>
    				PageNumber
    				xPosition
    				yPosition
    				valeur
    				sélectionnée (vrai/faux)
    				verrouillé
    				tabOrder
    
    "tabs": {
    		"radioGroupTabs": [
    			{
    				"documentId": "1",
    				"recipientId": "33160812",
    				"templateLocked": "false",
    				"templateRequired": "false",
    				"groupName": "Radio Group 1",
    				"radios": [
    					{
    						"pageNumber": "1",
    						"xPosition": "51",
    						"yPosition": "176",
    						"value": "Radio_1_3",
    						"selected": "false",
    						"tabId": "9e7822b3-7c0f-47cc-8bc8-774ee53b36cd",
    						"required": "true",
    						"locked": "false",
    						"tabOrder": "3",
    						"font": "lucidaconsole",
    						"bold": "false",
    						"italic": "false",
    						"underline": "false",
    						"fontColor": "black",
    						"fontSize": "size9"
    					},
    					{
    						"pageNumber": "1",
    						"xPosition": "51",
    						"yPosition": "137",
    						"value": "Radio_1_1",
    						"selected": "false",
    						"tabId": "ecb8c6b8-9a17-4f03-9053-94d6a6264606",
    						"required": "true",
    						"locked": "false",
    						"tabOrder": "1",
    						"font": "lucidaconsole",
    						"bold": "false",
    						"italic": "false",
    						"underline": "false",
    						"fontColor": "black",
    						"fontSize": "size9"
    					},
    					{
    						"pageNumber": "1",
    						"xPosition": "51",
    						"yPosition": "157",
    						"value": "Radio_1_2",
    						"selected": "false",
    						"tabId": "33adf214-9523-464e-a2f3-43d3a9789e65",
    						"required": "true",
    						"locked": "false",
    						"tabOrder": "2",
    						"font": "lucidaconsole",
    						"bold": "false",
    						"italic": "false",
    						"underline": "false",
    						"fontColor": "black",
    						"fontSize": "size9"
    					},
    					{
    						"pageNumber": "1",
    						"xPosition": "51",
    						"yPosition": "195",
    						"value": "Radio_1_4",
    						"selected": "false",
    						"tabId": "207d45f2-2c94-4c5d-93e6-32c11f7e6e09",
    						"required": "true",
    						"locked": "false",
    						"tabOrder": "4",
    						"font": "lucidaconsole",
    						"bold": "false",
    						"italic": "false",
    						"underline": "false",
    						"fontColor": "black",
    						"fontSize": "size9"
    					}
    				],
    				"shared": "false",
    				"requireInitialOnSharedChange": "false",
    				"requireAll": "false",
    				"tooltip": "Test Radio Group 1 Tooltip",
    				tabType (radiogroup)
    			}
    		]
    	}
    

    Comment changer les signataires intégrés en signataires distants, et inversement, à l’aide de l’API ?

    Lorsque vous changez de destinataire entre la signature intégrée et à distance, le composant clé est le clientUserId.

    Pour transformer un signataire à distance en signataire intégré, vous devrez mettre à jour vos définitions de destinataire de façon à inclure un clientUserId avec une valeur non vide/nulle. Exemple : les PowerForms utilisent un clientUserId équivalent à l’adresse e-mail du destinataire.

    Pour transformer un signataire intégré en signataire à distance, vous devrez mettre à jour vos définitions de destinataire de façon à inclure un clientUserId avec une valeur de "". Si le clientUserId n’est pas spécifié comme vide, il est ignoré et le destinataire ne passe pas à captif.


    Pourquoi est-ce que je reçois une erreur « Appel EnvelopeSends bloqué » ?

    Une erreur 400 avec un message d’erreur {"errorCode":"UNSPECIFIED_ERROR","message":"EnvelopeSends call blocked"} signifie que vous avez dépassé la limite d’enveloppes mensuelle de votre compte. Vous allez devoir mettre à niveau votre forfait de compte pour augmenter le nombre d’enveloppes envoyées ou attendre la réinitialisation de votre forfait.


    Comment modifier des messages d’e-mail à l’aide de l’API REST eSignature ?

    Pour modifier l’objet de l’e-mail et le message d’un brouillon d’enveloppe, incluez le code suivant dans le corps de la demande :

    {
      "emailSubject": "new email subject",
      "emailBlurb": "new email message"
    }

    Pour plus d’informations, reportez-vous à Enveloppes : mise à jour.


    Comment définir la langue du destinataire à l’aide de l’API REST eSignature ?

    Si l’option Activer les e-mails et les langues personnalisés pour chaque destinataire est cochée dans les paramètres d’envoi de votre compte, vous pouvez définir la langue grâce au paramètre EmailNotification > SupportedLanguage de la définition du destinataire. Pour plus d’informations sur le paramètre EmailNotification, reportez-vous à From the Trenches: Recipient Email Languages (Depuis les tranchées : langues des e-mails des destinataires).

    1. Remarque : La langue définie dans l’appel API ne s’appliquera qu’aux utilisateurs ne disposant pas d’un compte DocuSign et n’ayant pas interagi avec DocuSign par le passé. Si un destinataire a déjà utilisé DocuSign par le passé, ses préférences en matière de langue auront la priorité sur celles définies dans l’appel API.
    2. Si le destinataire dispose d’un compte, il peut définir la langue souhaitée en allant dans Mes préférences > Paramètres régionaux. Si le destinataire ne dispose pas de compte, la langue affichée est basée sur les préférences qu’il a définies pour son navigateur/système d’exploitation, mais il est possible de la modifier grâce à la liste déroulante Langue située dans le coin des sessions d’identification.

    Comment activer « Autoriser les signataires à réattribuer » sur une enveloppe à l’aide de l’API eSignature ?

    Configurez le paramètre « allowReassign » sur « true » dans la demande de création d’enveloppe. Pour plus d’informations, reportez-vous à Enveloppes : création.


    Pourquoi les utilisateurs ne reçoivent-ils pas d’e-mails à signer lors de la définition de « clientUserId » ?

    Lorsqu’un destinataire reçoit un clientUserId, il devient captif et ne reçoit pas de notification par e-mail par défaut. La fonctionnalité d’arrière-plan qui contrôle cela est Ne pas envoyer d’e‑mails aux signataires intégrés et doit être activée par l’assistance DocuSign . Autrement, si vous souhaitez utiliser un clientUserId mais que le destinataire reçoit toujours une notification par e-mail, vous pouvez utiliser une combinaison de signature à distance/intégrée décrite dans cet article de blog : From the Trenches: Hybrid Captive/Remote signing with EmbeddedRecipientStartUrl (Depuis les tranchées : combinaison de signature à distance/captive avec EmbeddedRecipientStartUrl).


    Hormis le premier signataire, pourquoi aucun destinataire ne peut-il signer l’enveloppe lors de la création de celle-ci à l’aide de modèles composites ?

    Pour régler ce problème, suivez les étapes de dépannage ci-après :

    • Vérifiez bien l’ordre d’acheminement spécifié pour chaque destinataire. Si un ordre vous est assigné, les utilisateurs ne pourront accéder à leurs enveloppes que lorsque ce sera leur tour.
    • Assurez-vous que vos noms de rôle et les informations de destinataire sont correctement alignés entre vos modèles en ligne et de serveur. Si les informations ne sont pas correctement alignées, des destinataires en double peuvent être créés ou les destinataires peuvent être complètement retirés de l’enveloppe.
    • Créez l’enveloppe en tant que brouillon en changeant le statut « envoyé » en « créé ». Si vous ouvrez l’enveloppe à partir du dossier de vos brouillons sur docusign.com, vous pouvez vérifier les destinataires ou l’ordre d’acheminement routage et rechercher tout ce qui ne semble pas avoir été rempli comme prévu.

    En savoir plus


    Comment modifier le titre du document et la ligne d’objet lors de l’utilisation de modèles composites pour créer des enveloppes ?

    Pour modifier le titre d’un ensemble de documents via un modèle composite, vous devrez fournir deux ensembles d’informations. Le premier ensemble est le modèle en ligne avec une séquence de 1: qui contient le nom du document mis à jour. Ensuite, vous ajoutez un serverTemplate avec une séquence plus élevée que la première. Cela provoque l’extraction des onglets et des informations de destinataire à partir du modèle de serveur, tout en modifiant le nom ou la structure du document d’origine.

    Afin de modifier la ligne d’objet, une fois vos modèles composites déclarés, vous pouvez ajouter un emailSubject à côté de l’état de votre enveloppe. L’emailSubject mentionné ici remplacera celui stocké dans le modèle.

    Exemple JSON :

    
    	{
    	    "compositeTemplates": [
    	        {
    	            "compositeTemplateId": "1",
    				"inlineTemplates": [
    	                {
    
    	                    Documents
    						{
    							"documentBase64":"....",
    							"documentId":"1",
    							"name":"New Document Name.txt",       <<<<<
    							"fileExtension":"txt"
    						}
    						],
    	                    "sequence": "1"
    	                }
    	            ],
    	            "serverTemplates": [
    	                {
    	                    "sequence": "2",
    	                    "templateId": "2932fad9-xxxx-xxxx-b598-484c51b5c0fe"
    	                }
    	            ],
    	        },
    
    	    ],
    		"emailSubject":"New Subject Line",						<<<<<
    	            "status": "created"
    	}
    
    

    Comment créer un destinataire conditionnel avec l’API REST eSignature ?

    Vous pouvez créer des destinataires conditionnels en utilisant la version 2.1 de l’API REST eSignature. Voir Spécifier les destinataires conditionnels.


    Connect

    DocuSign Connect est un service push qui envoie les mises à jour des données en temps réel vers des applications externes.


    Comment résoudre une erreur « le serveur distant a refusé la connexion » dans Connect ?

    Le message d’erreur affiché dans le journal des échecs Connect est la réponse de l’uri ayant été fourni via vos objets Connect. Voici quelques points d’échec possibles :

    1. L’URI n’est pas valide. Examinez votre objet Connect afin de vérifier qu’il n’y a pas de coquilles dans la section « URL To Publish » (URL à publier) de l’objet. Le protocole requis est https.
    2. Le serveur hébergeant l’auditeur a rejeté la tentative de connexion. Cela se produit généralement lorsque les plages d’IP pour DocuSign Connect n’ont pas été ajoutées à la liste allowlist sur le pare-feu du serveur. Reportez-vous à IP Range List (Liste des plages IP) pour plus de détails.
    3. Le plus souvent, si un auditeur est incapable de traiter une charge, vous recevez un message indiquant qu’une erreur 500 (serveur interne) est survenue. Dans certains cas, un refus de connexion s’ensuit. Nous vous conseillons de mettre à jour le schéma XML de l’auditeur : https://www.docusign.net/api/3.0/schema/dsx.xsd, et spécifiquement les objets EnvelopeStatus et DocumentPDF. Nous vous recommandons également d’examiner votre auditeur afin de vous assurer qu’il peut recevoir des fichiers dépassant une certaine taille. La taille des PDF DocuSign varie énormément, de quelques kilo-octets à 25 Mo ou davantage. Il faut que votre auditeur prenne en charge toutes ces tailles.

    DocuSign Connect prend-il en charge des charges utiles ou données JSON ?

    Oui, mais vous ne pouvez pas faire basculer une configuration DocuSign Connect existante pour utiliser des charges JSON. Vous pouvez créer une nouvelle configuration et sélectionner le format de données REST v.2.1 pour que Connect envoie des charges JSON. Pour plus de détails, reportez-vous à Data format: Legacy vs. REST v2.1 format (Format de données : hérité contre REST v2.1).

    Vous pouvez également spécifier des charges JSON utilisant eventNotification en ajoutant l’attribut eventData.

    	"eventNotification": {
    	"eventData": {
            "version": "restv2.1",
            "format": "json", 
            "includeData":  ["tabs","recipients"]
        },

    Pourquoi la valeur de hachage ne correspond-elle pas à « x-docusign-signature-1 » de l’en-tête lors de l’utilisation de l’authentification HMAC dans DocuSign Connect ?

    Voici les raisons les plus courantes de cet échec :

    1. clé secrète incorrectement copiée ;
    2. espaces avant ou après la clé secrète ; et
    3. non-inclusion de l’intégralité du corps brut de la requête Connect dans votre hachage. L’utilisation d’un outil comme Webhook.site peut aider à résoudre ces problèmes.

    En savoir plus


    Pourquoi je reçois cette erreur "HTTPS_REQUIRED_FOR_CONNECT_LISTENER" ?

    Alors que Connect est exclusivement HTTPS depuis un certain temps, à partir de l’hiver 2021, eventNotifications dans une définition d’enveloppe exige que le paramètre URL commence par HTTPS://.


    Références