I have an envelope I've created through the API and I set the status of it to sent during creation time so it was never sent to the customer. Then using receipientViewRequest I grabbed the link for it and sent that to the customer in an email so they can sign it. However, the link only works once. After the first click/visit, the link expires. Is there anyway to get a link to the envelope that doesn't expire?
The signing flow which you are using is called as Embedded Signing. In embedded Signing, you need to invite or ask your signer to visit your App, and when signer is ready to sign the document then at that time you should generate the signing URL (on-demand) and ask user to complete the signing. This link is one time use and by default, it expires in 300 seconds if not used. If you want DocuSign to send an email to the signer with your App URL so that signer is redirected to your App when he/she clicks the email link, then you can put your App URL in the embeddedRecipientStartURL property of the signer in the API call. By adding this property DocuSign will send an email to DocuSign and on click on Review Documents button, browser will be redirected to your App, once it reaches your App then you can generate embedded Signing URL so that you can host the Signing ceremony.
You should never send this embedded Signing URL link in an email or via any medium. If you want DocuSign to send an email to the signer so that signer can sign the document at any time then you should do Remote Signing, this can be achieved by removing the clientUserId for the recipient in your API call.
Related
Echosign allows us to send a document to Echosign to sign and then Echosign sends us a URL that we can then embed in our own email and send it to the signer. DocuSign's remote signing has Docusign sending the email to the signer instead. Is there a way to do what we did in Echosign in Docusign?
Thanks for this question Faulkner. I think you are confused about terminology.
Remote Signing
This means that an email is sent to the recipient with a URL that would enable them to sign on any device anywhere.
Embedded Signing
This means that the signing will take place inside an app. No email is sent. The app developers embed the URL for signing as part of the flow of their application.
For more information on Embedded Signing:
https://developers.docusign.com/esign-rest-api/guides/features/embedding
Re: Is there a way to do what we did in Echosign in DocuSign?
Yes, there are two solutions:
Easier: Change the branding of the email sent to the signer. See docs. You can update the colors, add your logo etc.
More work: Create your own "start-to-sign" url and include it in emails that you then send out. Here's the high-level flow:
Assuming that you want to send an envelope to Pat Smith to be signed. And you want to send the email link:
Create a record in your app's database of the signer's name, email, and other app-related information. Record the keyId of the record you've created. Note that there should be one record per recipient, not one record per envelope.
Create the DocuSign envelope with Pat Smith (and her email) as a signer recipient. Include recipient attribute clientId set to the keyId of the database record. Doing so will suppress the invite email and set the recipient as an embedded recipient. Save the resulting envelopeId
Update the keyId record in your app's database with the envelopeId from DocuSign.
Update the keyId record in your app with a new attribute of urlId. In this column generate a UUID. Do not use a sequence/key/etc. It is important that the urlId be unguessable.
Create a URL endpoint in your app. Something like https://apps.mycompany.com/thisapp/signFromEmail/[urlId]
Then, include that url (with the urlId for Pat Smith substituted for urlId) in your email to Pat. That will be the start-to-sign url for Pat for that envelope.
When Pat clicks on the url, your app should:
Look up the recipient record in your app database where urlId = the provided urlId
Use that record's data to create an EnvelopeViews::createRecipient call to DocuSign. The result is a url link that must be used within a couple of minutes.
Redirect the browser to the url link -- Pat will then see the DocuSign signing ceremony.
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.
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.
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.