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.
