We are using SOAP API with Document option. In regular way we do attach Recipient Id to Signature Tab to send a document for Signature, in this case only one signer can do sign on Signature tab.
We need to send a Document to group of people where anyone in the group should be able to sign on it.
I have come across a concept in DocuSign call it as "Signing Group" for this we need create group manually in the DocuSign account using all required email addresses.
But as per our requirement Email addresses are not static, Email addresses are dynamic that will vary every time we do send the document.
*Signing group option is might not relevant to our requirement. Is there any other go to achieve it...?
Thanks,
Vishwa
Based upon the current DocuSign API Documentation, it seems that the SOAP API does not support management of signing groups (create/delete/get/list/update) at this time. However, the DocuSign REST API does provide that type of functionality: https://docs.docusign.com/esign/restapi/SigningGroups/SigningGroups/
Related
I am using the DocuSign REST Api and noticed that the lifetime of a URL obtained using the EnvelopeViews API (https://developers.docusign.com/esign-rest-api/reference/Envelopes/EnvelopeViews/createRecipient) is only a few minutes. However, I have gotten emails in the past with DocuSign links. How are these links able to be added to an email (and therefore have a longer lifetime)?
Is there a separate API that can be used to get a longer-life link like the one in the email?
For example, here is an email that has a Review Document DocuSign link:
Good question. Here's what you can do.
Your application wants to let Larry sign a document using the
EnvelopeViews::createRecipient API call.
Your application should store the details needed for the API call in your app's database. Something like: envelopeId, signerEmail, clientUserId.
Create a guid for the database record and add it to the database record.
Now you can look up the database record via either the row's key or
via the guid. Ensure that the guid database column is indexed.
Now create a signing url that you will send to Larry. Something like:
https://myapplication.example.com/docusign-ceremony/[guid]
Send the url to Larry
When Larry clicks on the URL:
Your app is invoked
Look up the guid in the url in your database. You should find the
record that you stored there.
Retrieve all of the record's info: envelopeId, signerEmail,
clientUserId.
Call the EnvelopeViews::createRecipient API call with the data
and get back the signing ceremony url (that must be used within
5 minutes)
Redirect the user's browser to the url.
They'll sign the document(s) and then be re-directed back to your
application.
Done.
And guess what? This is pretty much what DocuSign does itself.
The response from Larry K above is correct, you would need to handle this on your side.
These are all the parameters that you can send as part of the request body for the POST {vx}/accounts/{accountid}/envelopes/{envelopeid}/views/recipient API endpoint and there are no options to set the expiration time for the recipient view that you create.
You could look into using PowerForms to see if they fit your needs. With PowerForms you can create a URL that users can click and it will allow them to fill out a specific DocuSign envelope. This might not fit your needs if you need to pre-fill some of the fields with information related to the specific recipient but it might be worth looking at.
PowerForms Documentation:
https://www.docusign.com/features-and-benefits/features/powerforms
Please correct me if I'm wrong but I think that your goal is creating the recipient view URL, creating an email formatted in a specific way and sending that email to the recipients.
If you use the branding feature you could specify the format for your email (if you want to use a specific message) and just send the envelope to your recipients. Once the recipients receive the email they'll see the message in the format that you specified and the link for accessing the envelope would be a regular DocuSign link that doesn't expire.
The link below shows how to create Brands in your account. Specifically signing brands would allow you to set the email content.
If you have multiple email formats you could create multiple brands and just specify the brandId when creating the envelope.
I hope this helps.
Branding:
https://support.docusign.com/guides/ndse-admin-guide-configure-branding
I'm working on testing our application and have the need to simulate signing of a document via the API. These aren't real documents I just need to be able to set the signing the order in a specific order but I don't receive emails for recipients until the previous one has signed. So is it possible to use the DocuSign API to sign a "Sign Here" tab? Or do I have any other options?
I haven't been able to find any clear information on this topic although I fear the answer is not. Looking through DocuSign's REST API there's a couple of endpoints that suggests I might be able to do this but I'm not quite sure it's referencing what I'm looking to do. The following endpoint has a GET and PUT function but not sure it's what I want.
{{baseUrl}}/envelopes/{{envelopeId}}/recipients/{{recipientId}}/signature_image
No, the DocuSign API does not have a functionality for 'robo-signing'.
If the goal is to check routing order, you could change a Signer to a Carbon Copy recipient: CC roles are immediately completed.
For reference, the signature_image API calls allow you to view or change a user's adopted signatures. They shouldn't be used to apply a signature to a document.
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.
We are using the DocuSign REST services and currently passing in the recipients required to sign the document from two People columns in a SharePoint document library. The client would now like to have it that they have secondary signers, e.g. the original users could sign but if they are not available their assistant must do so. What would be the best solution for this?
I noticed mention of something similar here:
Docusign multiple signers for one signature line
They want this to happen at run time though, so the email addresses get sent on the original request to create the envelope and this solution above speaks more to the concept of creating them via the DocuSign interface which is not ideal for them. Has anyone else tried this?
Do the assistants sign as themselves or on behalf of the original signer? I'm making some assumptions here, but most assistants would have access to their boss' emails, so presumably they'd have access to the DocuSign notifications that comes though. In that case, the assistant could simply sign as the original signer by clicking through to the envelope from the email. While this is usually a bit of an eyebrow raising move in terms of security, the reality is that many partners in law firms already delegate their authority to their PAs to sign on their behalf, and today these PAs have copies of all their bosses' signature images to place on documents.
A slightly better move, if the requirement is for the assistant to sign under their own name, is to go into the envelope from their boss' email and reassign the envelope to themselves. Then they will receive an email and they can sign under their own name and all of this will show in the audit trail.
Either way there isn't anything you need to do from an API perspective apart from ensuring the right features are turned on to allow signers to reassign.
The other option is using Signing Groups, but the groups need to be set up beforehand in the DocuSign account and your API call will enter the signing group ID (under the "signingGroupId" parameter) instead of the recipient name and email. This means either the boss or their assistant could sign if they are in the same signing group, but does not enforce one over the other.
A 3rd party website is offering our service to their members. When they sign up, members have to agree to our contract. Currently this is handled manually, with envelopes being sent through email. We want to streamline this process allowing members to enter their information into the web site, and then immediately be presented with a contract to review and sign.
The 3rd party web site will collect the member information, then use the REST API to create a draft envelope based on a Template and information the the member enters on the website. The application will then display the contract in the web page so that the user can review and sign it. The document workflow will ensure that signed copies are routed to appropriate parties within our company via email for completion.
We want the 3rd party web site to have access to an account to which we can share templates. We want the 3rd party application to have very limited capabilities trhough the API:
Submit requests using a User ID and Integrator Key that we provide. These credentials need be different from other User Ids and Integrator Keys under our account
Create a draft envelope based on the templates we provide
Post a Recipient View allowing the application to display the document for review and siganture (in an IFrame)
Receive the signing status via the return URL provided in the Recipient View post
Possibly request status for an envelope
The external application should not have access to other templates, documents, or unnecessry API calls.
We want to be able to cancel the application's access at any time.
Question: Permissions and API Limitations
Is the above scenario feasible with respect to establishing limited access to the DocuSign REST API? How would we set this up?
Do account user permissions limit API use, if the API is enabled for the user? I found these settings in the user permissions section of the documentation. I can make guesses as to how to set them, but I need guidance on the actual implications of some settings.
Submit DocuSign API Requests: true
Manage Account: false
Send Envelope: true
Manage Templates: Use
DocuSign Desktop Client: false
Transfer Envelopes to User: false
Allow sender to set email language for recipients: false
I assume "Account-Wide Rights" should be false, but under that option in the documentation, it lists RequestStatus as one of calls covered. Will an application embedding the signing process still have sufficient permissions to complete the tasks listed above if "Account-Wide Rights" is false?
Are there other settings or issues I need to consider?
Firstly, thanks for using DocuSign. The answer to your question is in a few different parts. To clarify, I am answering assuming:
1.) You are a current customer (or about to be one) of DocuSign.
2.) You have a plan that is set up to allow integration (IE you aren't trying to do all of this with a personal plan, or something like that).
There are a couple of terms I will use... Sender and Recipient. In this scenario, the THird Party Website is "the sender" and they are Sending the documents through YOUR DocuSign account, using the API. The people who are signing up for your service are going to be Envelope Recipients.
Just like with the post office, someone has to send, and someone gets the envelope.
So far so good.
So what will happen is that the third party website will write some code that knows how to talk to the DocuSign API, and you will need to know:
-DocuSIgn Account ID (this is your DocuSign account)
-The Integrator Key (this is the key that you will need to certify before going live, which identifies all those API calls as coming from them)
-Credentials to access your account (this can be either the actual creds, or a token, etc).
Now, there are two ways to do it. You can either have the third party website make the and send all of the envelopes as if they all came from a single "user" in DocuSign (likely) or if you know that a particular user should send out things, you can do that too.
I am going to assume that all of the sign up packets will be sent as if they came from something like Signup#company.com.
So you will make sure you have a user in your DocuSIgn account with that Email address and name, and make sure that user has the ability to send via the API (there's a setting in DocuSign admin), and all envelopes will be sent as if that "person" sent them.
You will need the settings for that user (the one that will "send" all the envelopes), set as you showed above. You would need the Account Wide access if you wanted to send "on behalf of" a different user. But you aren't doing that, so you should be cool.
The last thing is that you will need to make sure you have an envelope based plan (as opposed to a seat based plan) because otherwise, that one mega-user will look suspicious (sending hundreds of envelopes in an automated fashion).
I hope this answers the question?
-Dan