I am trying to integrate Docusign API into my web application. I tried using Envelope Views where I am redirected to either login page or the signing page. But I would like to redirect to Add Recipients page from within my web application where the user can add the recipients, prepare the document and send it to the signer. Is there any method as such exposed from Docusign API?
Re: But I would like to redirect to Add Recipients page from within my web application where the user can add the recipients, prepare the document and send it to the signer.
Is there any method as such exposed from DocuSign API?
Yes, the EnvelopeViews::createSender view enables your application to open the Sender's view of the envelope on the DocuSign web site. The user can then add recipients, tabs, etc.
Here is a code example that shows you how this works. You can download and run the code example in many languages.
Information Security Notice
This method, EnvelopeViews::createSender, provides full access to the sender's user account. When you use this view, the sender has full access to the user account. If the sender user account has administrative privileges, then this method also provides administrator access.
If your use case needs to enable a sender to update a draft envelope before it is sent, then either:
Configure each sender to have their own individual user account to use this API method.
Enhance your API integration so that this method is not needed. Your integration can create the tabs, recipients and other envelope settings as needed.
Related
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.
When using the Docusign API (in my case, via the Sandbox/demo env), in the signing view at the top of the screen it displays the name & company of the user account that was used to authenticate with the API.
However, because this is embedded signing from my app, I would have thought we'd only have one user account - for the app. So I want to change what appears at the top there - the information on the sender of the envelope. Either to be the user account that exists in my app that created the envelope, or just to state what company sent the document.
Are there options on the API to do this? I can't see any reference to anything like this in the envelopeDefinition JSON structure in the REST API docs.
You can use the DocuSign SOBO - Send On Behalf Of Functionality
The Send On Behalf Of feature permits automated sending through the API by one account user on behalf of another account user.
More information here
DocuSign has a Correcting option (to correct an envelope after it has been sent and before it is signed by the recipient) when you are logged into their site - is there a way to utilize this functionality through SFDC through a web service API? Where we send the unique envelope ID and the changed data to DocuSign, and they in turn revise the doc in the background? The recipient will see the updated document when he accesses the document to sign it.
Yes, you could do this from within an Apex class on SFDC. Don't use a trigger for the class, only a Lightening or force page, since triggered classes have too many restrictions on callouts to other services.
I am using the embedded signing api using JSON requests to create online signing sessions in the broswser. There is only one prospective configured in the template and the authencitcation method is email.
I do not want the email address that I am sending to receive an email notification. How do I turn this off. Ive looked at preferences--features to turn off email notification but cant find any setting.
Thanks in advance.
Login to the DocuSign web console as an Administrator in the sending DocuSign account, and navigate to Preferences >> Features. Enable (check) the Suppress Emails to Embedded Signers setting and Disable (uncheck) the Use Envelope Complete Email for (non-suppressed) Embedded Signers. Click the SAVE button (all the way at the bottom of the page) to save the changes.
These settings make it so that DocuSign will not send any emails to Recipients that you create via the API and specify as embedded/captive (i.e., by setting clientUserId property to indicate that they will be accessing the Envelope via your application).
Update
If you are using the New DocuSign Experience then follow the instructions here
See the Document delivery section.