I have a web service that creates Docusign envelopes with a PDF that needs to be signed. On my test environment, after the envelope gets created I query for the envelope status, as well as the recipient status. When using the API call, the respondents with bad email addresses have the status "autoresponded".
Now on my Docusign Connect implementation, I have two separate routes that get hit. One for when the email gets successfully sent or if the request is completed, and another one specifically for email delivery failures. When I had a single route, none of the recipients were marked as "autoresponded" like the API call returned (the API call result ends up being returned before the Connect implementation gets hit by Docusign).
After splitting them apart, I expected the email delivery failure-specific route to have the correct signature status. Unfortunately when this route gets hit, all recipients have the status of "Sent", regardless if their email is valid or not.
I'd contacted Docusign a while ago and their response was the number of events a single Connect implementation was listening for. By that assumption, this delivery failure-specific route should be getting a status of "autoresponded" like our API call is receiving, which doesn't seem to be happening. How can I get the Connect implementation to return the correct recipient statuses?
Every time I've opened a support ticket on their website, the corresponding account can no longer log in, meaning it's always a one-way communication to their support team. Has anyone gotten around this issue before?
My thought is that if the email failure route gets hit, flag that account as having a bad email address for one of the recipients and force the user to log into their accounts to see the actual status. Another option would be to query the API for that envelope's status, however I feel like a lot of delivery failures could easily trigger the max number of API calls.
Posting an answer, the original poster figured it out in the comment, but here is the answer for everyone else per Ricky Story:
"Return Recipient Auto Responded Status in Connect/API" that DocuSign Support should be able to enable.
To do that you would need to contact the DocuSign Customer Support and request them to enable this option.
Related
Our application is able to use DocuSign REST API to create an envelope for users to sign, and return the signed document to our application once the signing is done.
Recently, the issue is when the document signing has been completed, it is always missing the last signature. For example, we have indicated 3 signers to sign, but in the completed document it only shows 2 signatures.
The missing signature problem only happens to the completed document that is pushed back to our application. When the signers receive the signed document via DocuSign's email, all 3 signature are in the attached signed document.
Please let us know if there is any change to any API recently that cause us to face this issue, or what configuration do we need to fix. Thanks!
You say that your DocuSign "return[s] the signed document to our application"
If you're using Connect or the eventNotifications attribute for this, then you're using the DocuSign webhook system. Check that the webhook events you're interested in only list Envelope Complete. Not Recipient Complete.
Also check if the status of the envelope itself is complete. You've not indicated whether the problem is that the last signer is not asked to sign or if you're receiving a notification before the last signer signs.
If you're using a template, check that the template has not been changed and works as expected when it is sent from the DocuSign web app (vs the API).
Added
In the comments, the OP notes that they:
are using Connect webhooks
are requesting notifications for both Recipient Complete and Envelope Complete
In addition, from the question, I believe that the developer is using the default Aggregate queuing method.
What's happening
When aggregate queuing is used, notifications are initiated when a requested event occurs. But if a second requested event occurs before the notification from the first event is sent, only one notification will be sent for both events, and the notification content will reflect the later (the second) event.
So what is usually happening:
The last recipient signs (completes)
The recipient complete event triggers a notification. It is not yet sent.
The envelope as a whole becomes complete milliseconds after item 1.
The envelope complete event is triggered. The recipient complete notification has not yet been sent.
The notification is actually sent. The notification includes the envelope complete information.
What will sometimes happen:
The last recipient signs (completes)
The recipient complete event triggers a notification.
The DocuSign system sends off the notification. It shows that the recipient is complete but not the envelope.
The envelope as a whole becomes complete.
The envelope complete event is triggered.
The notification is sent. The notification includes the envelope complete information.
Conclusions
If you are only interested in the envelope complete status (everyone signed) then do not request the recipient complete events!
If you want recipient complete and also want envelope complete events, then your application needs to inspect the incoming notification to determine the envelope's status.
Added re why not recipient_complete?
recipient_complete events should only be requested if your application will take action as each recipient in the envelope completes. (A signer is complete when they sign, a cc recipient is complete when the email has been sent to them, etc.)
If your app will only take action when the envelope as a whole is complete, then asking for recipient_complete events too will only cause additional notifications that can be confusing to your app's logic.
In my returnUrl handler, I am using list documents.
In the returned array, how can I figure out if the document has been signed or not?
Thanks!
Your return url handler will be called with a query parameter event as discussed in Inbar's answer.
But you should not use the query parameter for making business decisions since a bad guy could easily call your return url and simply tack on an event=signing_complete query parameter--spoofing your application.
Instead, when your application needs to know if the envelope has been signed or not, it has two categories of options:
Ask DocuSign
Your app can call the Envelopes::get method to determine the current status of the envelope. Other API methods can also be used for this functionality.
Design your app such that you do not call DocuSign about a particular envelope more often than once every 15 minutes since such behavior is considered polling and is not allowed.
Webhook: DocuSign will call your app
You can set up a webhook with DocuSign so that the eSignature platform will call your application when the envelope is complete (signed by all the signers, etc).
Use the DocuSign webhook HMAC feature to guarantee that the notification message came from DocuSign (was not spoofed) and that it was not altered in transmission.
By using AWS or equivalent, you can easily receive the notification messages behind the firewall, with no firewall changes. And AWS will not charge you for the first million notification messages per month. See the connect-* repos on github.com/docusign
Dashboards
If your app wants to present a dashboard to a business decision maker about the status of your envelopes, then relying on the event query parameter is fine. But before your app does anything that costs real money, eg initiate goods or services to be provided to a customer, make sure that the envelope has been signed by using one of the two techniques above.
The URL you get back from DocuSign has an event parameter and looks like this:
http://www.acme.com?event=signing_complete
signing_complete means it was signed.
https://developers.docusign.com/esign-rest-api/guides/features/embedding has the full list of other events in the "Determining Recipient Action" section of the article.
When I upload a document using the Docusign API on the Sandbox and then send the document I do not receive any emails.
I've also logged on to the sandbox and tried to sign the document but don't have the option - status seems to be waiting for others (even though the document is only sent to my email).
When I create the envelope through the web site and send, I do get the email.
This has only started to happen in the last day or two. Had been working fine for us.
Is there a problem with Sandbox?
The issue was that we were passing the ClientUserId property for the Signer in the API call when creating the envelope.
I wasn't aware but this actually stops the notification emails being sent.
You can check Docusign system status at
https://trust.docusign.com/en-us/system-status/
When I wasn't received emails in the develop environment, it was because I hadn't set:
{ "status": "sent" }
...in the envelope definition. This is the documented way of indicating that you would like this envelope to be sent rather than just "created", which sets it as a draft.
Once any document is sent for signature, we can see that document status like in process, completed. Also email notification is coming to document sender mail. Are these features exposed by docusign rest API?
Yes, absolutely. The status updates are delivered to your program via a "webhook" -- you register a url with DocuSign and then DocuSign calls your app when a change occurs.
You can create a webhook subscription at the account level or for individual envelopes.
See the docs. Recipes are also available at the DocuSign Developer Center.
Added
You can also determine the current status of your signing requests (your envelopes) by polling the DocuSign platform. However, this is actively discouraged, and in any case, you can't poll more than once per 15 minutes for a given envelope. The docs discuss this as well.
There is a documentation about possible envelop status value from docusign for a given envelope.
Howver i am trying to understand if there are any documentation which lists out the possible "Action" value from docusign in the "Audit_event" REST API method.
The reaosn is I am storing the audit events locally to avoid multiple API calls and i wanted to account for all the possible action values.
Thanks for reading
Since there were any documentation provided, i am including the staus i have seen based on my reverse engg
Registered
Sent Invitations
Printable Copy Delivered
Printable Copy Attached to Email
AccessCode Passed
AccessCode Failed
Viewed
Signed
Approved
Resent
Voided
Declined
Correction Initiated
Correction Cancelled
Viewed In-Session
Corrected
I've never seen any documentation for possible values of the action property within a GET Envelope Audit Events response -- to the best of my knowledge, none exists. You might be stuck having to 'reverse engineer' to determine possible values. i.e., create envelopes via the DocuSign web console, act on them in a variety of ways (both as Sender and as Recipient) -- for example: Send Envelope, Void Envelope, Decline Envelope, Sign Envelope, View Envelope, Pass Signer Authentication, Fail Signer Authentication, etc. etc. etc. -- and then examine the corresponding action values that appear in the GET Envelope Audit Events response for those Envelopes.
Obviously this approach is not ideal, since someone fairly new to DocuSign won't necessarily know all of things that can be done with an Envelope, in order to trigger the various action values in the API response. Perhaps someone from DocuSign will see this post and chime in with a list of all possible values...or better yet, add this info to the API Guide one day soon.