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.
Related
Which api and body request i need to send for creating a multiple signers can sign the docuSign without sending them a email , Can i please get the help of the process :
onClick of a link we should be able to navigate user to docuSign url and once first signer completes sign then it needs to trigger a mail to second signer using the api requests in the postman
There are 2 types of ways that you can request signatures via the API:
Embedded Signing - URL that you get from API, it expires in 2 minutes. You can use this inside your application for signing. You CANNOT EMAIL this URL!
Remote Signing - DocuSign emails the recipient. The link in the email can be used for a few days, it doesn't expire quickly. This URL cannot be embedded in your application.
You can switch from 1 to 2 and back as you need. You can have different recipients use different signing. It's fully flexible and up to you the developer how to use these. Just as long as you know how to do 1 or 2.
You indicated you are using the Apex Toolkit so here are code examples:
https://developers.docusign.com/docs/salesforce/how-to/embedded-sending-signing/
https://developers.docusign.com/docs/salesforce/how-to/send-envelope/
We have ASP.ET MVC Web application. We are using Docusign SDK For C#.
We are planning to go Live with DocuSign Integration and We looked at DocuSign limits (specially 15 minutes get request limit).
We need an advice on how to avoid violation in Envelop Correction scenario. Steps are as given below.
Get status of envelop
Get recipients of envelop and show it user in the GUI
User updates email in the GUI and submits form
On backend we Get recipients again with all tabs and custom fields, Update email address
Call Update recipients method
You see on number 4. It is 15 minutes violation. How to handle this scenario?
We don't want to create Whole mechanism for Saving/Caching DocuSign Recipients data and statuses. As those statuses can change from DocuSign or some of the recipient can decline or void envelop. We want to fetch latest recipient data to update on the time of execution.
I agree with Inbar that you could store the results of the first get_recipients call. You could either store it in the user's session state (server side) or send it all to the browser and then have the browser return it.
I'd go with session state
Saving data in the session state isn't a big deal.
Re:
As those statuses can change from DocuSign or some of the recipient can decline or void envelope.
So you're worried that while the application user is updating an email address, the envelope will be declined by a recipient?
In that case you could lock the envelope while your user is updating it. Or you could not send the envelope until after the user has updated it. Or if you get an error while updating the recipients, that would be the time to do the extra recipients_get.
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.
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.
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.