Trending Topics: Latest from our forums (June 2020)
Here are some of the latest popular questions that the DocuSign developers community asked on Stack Overflow in the month of June 2020. You too can ask questions by using the tag docusignapi in Stack Overflow.
Thread: Optional recipient role template docusign
Summary: The developer is trying to use a single template with either three or four recipients. One of the recipients is optional. They are having issues accomplishing this. They want to create the envelope in draft and send it later.
Answer: When specifying template roles, you can omit any roles that you do not wish to be used. Even if these roles already have tabs (signing elements) associated with them, if they are not included in the body of the POST request, they’ll not cause any issues when the envelope is sent. If you want to create the envelope in draft and send it later, you should set the mege_roles_on_draft query parameter to true to ensure these other roles are removed.
Thread: What happens to DocuSign envelope notifications when webhook fails?
Summary: The developer is asking about the retry mechanism that DocuSign Connect is using and how it works when events fail to acknowledge.
Answer: When registering a webhook with DocuSign Connect, you can specify RequireAcknowledgment = true. This option ensures that your server receives the message from Connect by requiring that your server acknowledge it. If the message is not acknowledged within 24 hours, DocuSign Connect will send it again. It will do so up to 10 times or until an acknowledgement is received. This is different from a negative acknowledgement situation when DocuSign receives a 404 or 500 error. In that case, the message would fail and simply show in the Connect logs.
Thread: RestAPI “create” envelope where the envelope belongs to a different user than the API user?
Summary: The developer is asking how to create envelopes that belong to a different user other than the user by which the API request is authenticated.
Answer: There are a few options here. First, if the developer can use JWT (JSON Web Token) authentication, then they can specify a different userId for the user to impersonate before they receive a token for API calls. If the goal is just to share the content of the envelope with another user, they can do that by adding that user as a CC recipient of the envelope. Finally, if they need to actually perform a custody transfer of an envelope, they can only do this via the eSignature SOAP API.