I am getting an issue in the sandbox account of DocuSign I need to create an envelope and send it through Url so I used an envelope View response give and Url it is working fine with the same browser were where I logged in with the DocuSign sandbox account but in the incognito mode, it gives an error.
need to know it will work in the production account or not?
The URL for the embedded signing view should be used immediately and must be used within 5 minutes.
In addition, any specific envelope cannot have more than one embedded signing view active at a time. So if an envelope has two embedded signers, your application must ensure that only one the signers will be signing at a time.
I think you let the url expire.
Whatever works in demo (developer account) will work in production. (Assuming your paid account includes the features that your app is using.) Your app should never cause the error that you're seeing.
I suggest that you start with the QuickStart code examples and see how they handle embedded signing.
Related
Context
My team is working on an integration between a Web Application and DocuSign, where the user may send files to signing from our App to DocuSign (creating an envelope with the files).
In the envelope info inside our app, the user should have a link to be redirected to DocuSign (preferably to the Management page, but Home one is also acceptable).
Question
Since there isn't an endpoint on DocuSign eSignature API for getting a redirect URL (such as EnvelopeViews), and I couldn't find a document mentioning direct access to DocuSign eSignature (such as the one existing for DocuSign eSignature Admin), my question is...
Is there a known redirect URL to DocuSign eSignature that I could trust it won't change, so I can use it on our application?
I found out (looking at the authentication process) that the following URLs work for what I want...
https://appdemo.docusign.com/authentication?back=/home (Sandbox)
https://app.docusign.com/authentication?back=/home (Prod)
https://appdemo.docusign.com/authentication?back=/documents (Sandbox)
https://app.docusign.com/authentication?back=/documents (Prod)
But can I trust they won't change (since they aren't documented) and use them on my app?
For the management/web app for users, there's a way to do that with the API, you get back a URL that is pre-authenticated and is the recommended way to do that.
See here for code examples in different languages.
As for the administration/settings part, you would have to do it the way you indicated. We cannot guarantee this URL would never change, but it's not something that happen often if at all. However, users would have to log in (authenticate) when they are redirected unless in the same browser and already logged in.
createSender creates a URL, which I would like to use to let the sender preview the document before it's send out. Hence the documents are created using templates and and the API.
The link which is created would lead me out of my UI. Does the user need to sign in? Future plan is to have many user's, which have no DocuSign account.
For embedded sending Your app will have to authenticate the user. If you are doing a Service Integration then your Api account will be used as the sender.
Once the sending url is generated using the createSenderView api, there is no authentication required to access the URL.
You also have an option to build a User Application using the docusign Api where your App can support sending from multiple accounts.
The createSenderView requires that the person is a DocuSign user (with their own account and password).
Only DocuSign users can send. We charge for sending, not for signing or receiving.
What exactly do you want to preview? (And why?)
the documents themselves? Use the EnvelopeDocuments resource. You can also preview the thumbnails of the documents.
the documents with the "fields" ("tabs") that indicate where people will sign? I'm not sure that is do-able.
or the recipients and their routing order? Use EnvelopeRecipients: list method.
Added
Another solution is to use a dummy certified delivery "recipient". Add this recipient as the first recipient. This will block the envelope from proceeding on the recipient routing.
Then get the envelope's documents to show as a preview.
Then, if ok, alter the envelope's recipients to remove the certified delivery recipient. The envelope will then continue on with the first "real" recipient.
I'm using DocuSign's REST API to create envelopes in embedded signing mode. With the function CreateRecipientView i get only a temporary link. But i would prefer to get an permanent link like in the notification mail. How can i get this link/URL?
Getting permanent signing links is not possible using the DocuSign rest API.
For remote signers, only the signer can receive the signing link through email. No one else will have access to the signing URL.
Setting permanent signing/access link is possible with "embeddedRecipientStartURL" by using a captive recipient aka "clientUserId" and your own URL endpoint whereby you authenticate your users and determine if they can access the envelope via a Request Recipient View.
Documentation here.
You can also request emails be sent per captive recipients as well as many other "Portal" centric options that put you in full control of the user experience.
To give your signers permanent links, your application creates the links by itself. Eg myapp.myserver.com/signing_links/95a086f7-a76e-40ec-938e-987be996d220
The number should be a guid, not a database record key. This is needed to prevent someone from guessing what one of these permanent links is, so they can't read (or sign!) someone else's documents.
When someone opens their browser to go to one of the signer links, your application looks up the guid in the your app's database. The database record will include the DocuSign envelope_id and the recipient_id that the link represents.
Next your app uses that data to request an embedded recipient view link from DocuSign. Then (if you get a good response back from DocuSign), your app redirects the user's browser to the signing page on DocuSign.
(You'd get back an error from DocuSign if the recipient had already signed, or the envelope had been voided, etc.)
Guess what? The above is more or less how DocuSign gives out the "permanent" links in its emails--those links always redirect to one of the 5-minutes-only signing ceremony links.
Remember that you need to authenticate the signers, or include additional authentication options in your envelope, since you don't know who is going to end up pressing one of your app's signer links.
Setting vs Getting permanent signing/access link is possible with "embeddedRecipientStartURL" by using a captive recipient aka "clientUserId" and your own URL endpoint whereby you authenticate your users and determine if they can access the envelope via a Request Recipient View.
https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Recipients/Signers%20Recipient.htm
You can also request emails be sent per captive recipients as well as many other "Portal" centric options that put you in full control of the user experience.
So Net/Net, LarryK and CodingDawg are correct, each from a specific view. It ultimately is up to you to decide which way works best for your application and users.
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.
At my company, we are implementing some parts of DocuSign, and have run across a scenario we believe the REST API does not support.
There are times where user's in our system change email addresses. We want to push this change to DocuSign for the user, without the user ever requiring to log in to DocuSign and manually change their email address via the console. This, of course, changes the username the user authenticates with on the login page of DocuSign.
Is it possible, using the DocuSign REST API, to change a user's email address (which in effect changes their login name do DocuSign)?
The DocuSign system does not support changing the email address through the API (REST or SOAP). This is mainly due to security restrictions - unfortunately your users will need to manually go into the DocuSign Console and go to Preferences to change their email address.
One thing that might make this process a little smoother is to automatically open the Console for your users when they request to change their email address. You can open the Console in an embedded iFrame in your site or app and from there they can change their account info. You would just need the user's credentials (along with the integrator key of the integration) and you can open the console for them.
The third API Walkthrough - Embedded DocuSign Console - illustrates exactly how to do this in 6 different languages (PHP, Java, Javascript, Python, C#, and Objective-C). You just need to make the following call from your environment, with just your accountId in the body of the POST request:
Method
POST
URI
/accounts/{accountId}/views/console
BODY
{
"accountId": "XXXXXX"
}