Embedded signing flow returns ttl_expired status - docusignapi

I have implemented DocuSign's Embedded signing flow with our application. Our use case : customer of our app sends email with link to the client that has to sign a document. That is our app link. On clicking on email we are opening DocuSign (in IFrame of our app) and open url as following :
https://demo.docusign.net/Signing/startinsession.aspx?t=776a1a9c-72c6-4c62-9243-2807db18f78a
If user clicks on link and finish signing/declining everything goes OK. Elsewhere user opens a link, do nothing and re-open a link immediately DocuSign sends ttl_expired status. Same response I get if user clicks on link after some time - let say 1hour.
As I found online, for this flow :
Recipient Tokens expire five minutes after they are issued by DocuSign. If a Recipient Token URL is invoked after it is expired, the user is re-directed to the Callback URL specified in the RequestRecipientToken request with event code TTLExpired.
Recipient Tokens expire upon being successfully invoked.
Active Recipient Tokens expire if the envelope is voided.
Developer Guide 85
Five minutes is the default "Time to Live" for Recipient tokens. This is a configurable setting.
Source
If it is like that, which DocuSign flow can meet our use case, or I have to change something in existing flow ?

You do not need to create a new envelope each time you encounter this error. In fact, that's a bad decision as that will start to eat up at your monthly envelope limits that are allowed on your DocuSign account plan.
Instead, if you generate a signing URL and the recipient opens it but does not sign and closes out and eventually needs to get back in and sign that envelope, you can simply generate a new recipient view (signing URL).
With the newly generated URL the same rules apply... if they don't use it within 5 minutes or they open but don't sign the once again you'll need to create a new URL token, but that's much better than wasting a whole new envelope. That simply counts as one extra API call, which you are allowed 1,000 per hour per account.

The retrieved URL is one-time use and expires after 5 minutes. Once Docusign detects that you have loaded a retrieved URL, it will no longer work. As stated in a previous answer, if you haven't loaded it within 5 minutes, it will also no longer work. The ttl_expired code will appear in both cases.
You just have to request the signing URL again if its used or expired. Do not recreate the envelope.

Related

DocuSign create a long lived embedded signing url?

The URL returned by the embedded signing url API method EnvelopeViews:createRecipient only lasts 5 minutes.
How can I get an embedded signing URL that will last longer?
The embedded signing URL time to live is only 5 minutes.
So the answer is to give your signers a customized url to your application. Then, when your signer clicks it, your application first obtains an embedded signing URL from DocuSign and then responds to the signer with a redirect to the URL.
Creating the customized URL
Create a database table in your application with columns:
ID
url_lookup_guid
account_id
envelope_id
signer_email
signer_name
signer_clientUserId
envelope_expiration_date (optional, see below)
When you want to create a unique URL for an embedded signer:
generate a guid. It will be used as the url_lookup_guid value
Create a record in the database table.
The url will be something like myapp.mycompany.com/sign/[url_lookup_guid value]
Creating the embedded signing ceremony
The user opens (GET call) the url you gave them. Eg myapp.mycompany.com/sign/1234567-1234-1234-123456789
Pull out the guid valid from the URL
Look up the record in your database
Use the other values in the record to make a call to EnvelopeViews:createRecipient
Receive the embedded signing URL response to the API call
Redirect the signer to the URL
Remove the database record or mark it as used.
Clearing old database entries
As noted above, you can delete database rows once they're used.
To clear out entries that were never used, a batch process can check the database each day for obsolete entries where the envelope has expired.
Either record the expiration date, or auto-create an insertion date
in the database. Then, once your account's default expiration time has been exceeded, make an API call to DocuSign to check that the envelope has indeed expired. (Its expiration date may have been extended.)
Notes
The URLs that you create can last as long as you wish, or until the envelope expires within DocuSign, whichever comes sooner.
The URL will enable the person to sign the envelope, so you'd probably want to include additional signer authentication from DocuSign to ensure that the signer is who they say they are.
Don't use the database's ID as the lookup key since you want to ensure that someone can't guess the ID of a record. Use a random guid as the look up key.
Your app will need an access token to make the API call to DocuSign. Since this is an autonomous task, use the OAuth JWT grant flow.
Don't create a new access token per invocation, cache the current access token.
Since it can take a couple of seconds to create the redirect URL (or more time if you need to obtain a new access token too), you might want to first return an intermediate page that shows a please stand by message and makes an Ajax call to your app to obtain the URL for the redirect.

How do you get the preparation redirect URL for a created Envelope?

I'm using a service account to send an envelope on behalf of another user. Using the API, I'm then creating an envelope in the "created" status for manual tab placement. Once I get the EnvelopeSummary back from the DocuSign API, I'd like to create a URL that I will send send back to the "send on behalf of" user so he/she can easily begin to place tabs.
I've looked into using the CreateSenderView/CreateConsoleView methods, however I don't know the AccountId/Password of the "send on behalf of" user nor do I want to use their information. Instead, I'd like to redirect the user to DocuSign where they can login and then after login, be redirected to the envelope.
I've also looked into creating my own URL from the envelopeId:
string envelopeId = "1ddff790-ad2d-4fb6-87c2-4b5e449898c9";
string redirectUrl = "https://appdemo.docusign.com/prepare/" + envelopeId;
This appears to redirect the user to the envelope if they are logged in, and if not, they will be prompted to login and then redirected. This is the functionality I am looking for, however, I'd like to use the API to generate this URL if possible since I'm not sure whether the referenced URL will remain static over time.
Any ideas?
If you haven't already done so, I'd suggest that you review DocuSign API documentation for the Send on Behalf Of (SOBO) feature. As the documentation describes:
The SOBO feature can only be used when both users are members of the same DocuSign account.
You (your application / UI) must collect username and password at least one time from the user whom you're sending on behalf of -- because you need their username and password in order to obtain an access token that can subsequently be used to submit API requests on their behalf. Since tokens do not expire (and are valid even if/when the SOBO user changes their password), you only need to collect username/password one time from the SOBO user, then use those credentials to generate an access token which can be used indefinitely to send on their behalf.
I would not recommend using the envelopeId to create your own URL, as this functionality is not supported by DocuSign -- even if it works today, there's no guarantee it'll continue to work in the days ahead.
Finally, issuing a Create Sender View request (using SOBO) will return a URL that can be used to launch the sender (tagging) view for the specified Envelope. Do note, however, that the URL will expire after a short period of time (5 minutes?) -- which means that you should not issue the Create Sender View request to retrieve the URL until the user (sender) is ready to tag/send the Envelope. For example, issuing the request to generate the URL and then emailing that URL to the sender would not be feasible -- since there's no guarantee that the user (sender) would open the email and click the link to launch the sender view before the link expires. Instead, you should provide the sender with a way to indicate to your application when they are ready to tag/send the Envelope, and then issue the Create Sender View request at that time and redirect the user (sender) to that URL immediately upon receiving the URL.
Update (Legacy SOBO)
#EnterTheCode -- thank you for the clarification that you provided in the comments. Your understanding of Legacy SOBO functionality is correct; that is, it does not require that you obtain an access token for the SOBO and it does not require that you obtain the SOBO user's password. You can simply include the X-DocuSign-Authentication request header to specify the username and password of your "service account", the integrator key, and the email address (or user ID) of the user whom you're issuing the API request on behalf of.
(Side Note: Although Legacy SOBO is apparently still supported, it's no longer recommended for service integrations. Instead, DocuSign now recommends this approach.)
Putting SOBO authentication technique aside though, the rest of my original answer still applies to your scenario. That is, to retrieve a URL that can be used to launch the sender (tagging) view for the specified Envelope, you'll need to use the Create Sender View operation. And, as mentioned previously, the URL that's returned by that operation will expire after a short amount of time -- so be sure to account for that in how you design your implementation.
Why you want to use SOBO, if you want someone to update the envelopes then you can add that user as first recipient in the envelope with recipienttype as "Allow To Edit" ("editors" in API term). With recipient type as "Allow to Edit", DocuSign will send an email to the recipient and then recipient has to login into his DocuSign account, after that user will be able to access the envelope and can do the editing of the envelope like doing tagging of document with DS Tabs, adding, removing recipients etc, in same way as "Sender View". In this way you don't need to create a webpage for embedded sending view.

Docusign RequestRecipientToken no longer working

I am using Docusign SOAP API for signing the documents. When using the RequestRecipientToken method, it returns the URL for signing the document, but it was no longer working and it asks docusign username and password.
How can I get a URL that will used in anytime and will do auto signing?
Typically if you want to bypass the login screen you'll either want to turn off the signer login requirement, or use an embedded signing session.
When creating the envelope, specify a clientUserId for the recipient. Then when you make the POST call to retrieve the recipient view, if you include that ID a URL will be sent back that will allow them to click and access their envelope without having to authenticate.
These URLs do expire after 5 minutes, so you can't really have a static link that works at all times.
DocuSign also does not support automatic signing, as the manual signing process is part of what validates an envelopes audit trail.

DocuSign: when using an embedded signer, how do you send email to user if they select "Finish Later"

DocuSign: when using an embedded signer, how do you send email to the signer if they select "Finish Later?"
I have tried to deselect the "Suppress Emails to Embedded Signers". But that did not seem to change anything.
If it is not possible to send a signer an email, how does they get back to the document, since the url that is generated is only good for 5 minutes?
DocuSign offers two main methods for initiating workflows with your recipients: Remote Recipients or Embedded Recipients.
Remote Recipients, which is the default, receive an email from the DocuSign platform which has a link that they use to open the signature request through a browser and sign through the DocuSign Web App (i.e. website). In this scenario recipients are guided through the DocuSign website and have full access to all features and settings.
On the other hand, Embedded Recipients do not context-switch, wait for an email, and then sign through the website. Instead, when you embed a given recipient you are telling the DocuSign platform that YOU are taking care of everything, such as preparing the signing URL, delivering to the user (recipient), and handling the callback once they are done signing.
In this case, whether they sign the document, decline to sign, close the window, or do something else like hit the "Finish Later" button, there will be a query parameter appended to the return URL you configure so that you can determine what action they took. For instance if they declined to sign the document and your returnUrl was set to https://www.docusign.com/developer-center the callback would look like:
https://www.docusign.com/developer-center?event=decline
Therefore, when you Embed a recipient and they either do not sign in time (due to the 5 min expiration of the URL) or they try to access it more than once (they are one-time use only) your app will need to parse the returnUrl to determine what action they took and simply generate a new signing URL when needed.

DocuSign API Captive Recipients

I have been creating DocuSign envelopes using SOAP based API call "CreateAndSendEnvelope".
When I create an envelope using captive recipients into my DocuSign demo account..
1) When I include captive recipient's e-mail address in the SOAP request, would a captive recipient get a signed document back? I am not able to get the signed document back. I get an email with the notification that I signed the document.
2) My session never times out. According to DocuSign documentation, the session times out in 5 minutes and it is a configurable setting. Where should I look at that setting and how should I test the session timeout?
3) When I request recipient token once and if I make the request to get the token within a short period of time, I get an error. After I wait for a few minutes, I am able to retrieve the recipient token fine. Is there a time frame that I should consider while making a request to retrieve the recipient token?
1) You can control whether or not to include the completed documents in the email through an account setting. Login to the Console and go to Preferences -> Features, and on that screen you should see an option labeled "Attached Documents to Completed Envelope Email".
2) The default session timeout is actually 20 minutes, not 5. And if you want to change that you need to contact your Account Manager - it's not a setting you have direct access to.
3) Embedded Sending and Signing URL tokens are only valid for 5 minutes, after which they expire. At that point you simply need to generate a new URL token for the given recipient.

Resources