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.
Related
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'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.
In docusign is it possible to create a signing request via the web interface and then retrieve the sigining URL via the API
at the moment, I update the Envelope using the API to attach a clientUserID as this is lacking when created via the web interface.
Then I retrieve the signing view url however, there is no signing tab when navigating to that url. The only action I have is to close.
I have tested using the API and the envelope contains signing tabs so I'm not sure what the issue would be.
Any help would be much appreciated!
When you send a DocuSign envelope if you assign one or more tabs to your recipient it becomes what's known as a Free Form signing experience, where the recipient decides where to sign the document.
On the other hand if you specify one or more tabs for the recipient then it's a Guided Signing experience. In guided signing the recipient can only sign and take actions at the tabs the sender has specified.
It sounds like you are successfully creating the envelope and signing URL but that there are no tabs configured for the signer. If that's the case you should confirm your code is identifying the recipient correctly by specifying the name, email, recipientId, and clientUserId values.
I would also check that the tabs are being set in your request body correctly for the given recipient. First get the recipient information for the envelope using the EnvelopeRecipients: list API to ensure the data is what you expect, then generate the signing URL using the corresponding data.
Using this python example from github as an example, I wrote an R package for interacting with the DocuSign embedded signing API.
I don't appear to fully understand the workflow for embedded signing, and I am hoping someone can help.
Here is what I would like:
I have an application with a sign up page. When users sign up I would like them to sign a document. So when they submit the sign up form, I generate an envelope using a template, and use their name and email in the templateRole parameter. I get a URL which I send the user to, which allows them to sign the document.
It appears though that the actual workflow involves sending an email to the signer first, and having them sign from a link in the email. This does not seem very "embedded" so I am a bit confused. Is this because I am using the sandbox API?
I see that that there is an authenticationMethod parameter, which takes values of either email, or HTTPBasicAuth or Password or PaperDocuments. Is this the reason it is using email instead of directly sending the user to a page where they can sign because I am chooseing email as the authenticationMethod?
Have I fundamentally misunderstood embedded signing?
The script you are referencing is for Embedded Sending.
The Embedded Sending view of an envelope allows users to edit the tabs, documents, recipients, and other settings of draft envelopes before sending them out for approval
So you are basically giving the Signer access to potentially modify the envelope(Add more signers, remove documents etc). The sender view should never be presented to the Signer.
If you are looking for Embedded Signing, then see this code
Embedded Signing - or the Recipient View workflow - allows users to sign directly through your app or website. When you embed your recipients you are telling the DocuSign platform your app will generate signing URLs, authenticate your recipients, present the signing request, and re-direct once the transaction is complete.
I am using the DocuSign API in an embedded manner. I create an envelope and add signers, the first signer always being set as embedded. This allows me to retrieve a URL that is then embedded in an iframe.
However, I also wish, to trigger an email (as soon as the envelope has been created, NOT upon completion) that gets sent to the primary recipient/signer as if they were a nonembedded signer.
I tried adding the signer twice, with the same role, to the recipients, but that didn't work. No email was sent.
Is there a way to accomplish this?
I believe there is a setting to enable this but that it needs to be enabled by someone on DocuSign's side, like your account manager. If you do not have an account manager yet please respond to the auto-generated emails that were sent out to you once you created your account, you should have 3 of them.
The account settings available are only for Completion emails. However, the REST API also supports an embeddedRecipientStartURL parameter on the signer object that triggers a normal DocuSign email. The value of this parameter is the URL that should be included in the email. This means you can link back to your own application and request the recipient view as normal.
Check here for more detail: Signer embeddedRecipientStartURL. Note: if you set this to a value of "SIGN_AT_DOCUSIGN" then DocuSign will provide its own URL and take care of signing. The trade-off is that you won't be able to initiate any bespoke authentication you are doing in your own application.