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
Related
Using the REST API for remote signing and it's been working great for about a year now.
We have a user of our system that wants to send documents for e-signature, and I'd like to limit their access to their own documents, let them get the notifications of document completion, etc.
I know I can create additional users in the admin section but I'm not sure of where to look from there. Is any of the rest possible?
Yes, add the person as a regular (not admin) sender in your DocuSign account. They'll only be able to see envelopes (transactions) that they sent.
They can also see envelopes that were explicitly shared with them by another sender
Added: authenticate as a different person
Your API application sends envelopes by using the credentials of an account member. If this is a non-person such as "finance#yourCompany.com" then we call that a "system user."
Your question was how to send envelopes from a sender who is not an administrator. The answer is to authenticate to the DocuSign API as that person. This can be done with the OAuth JWT or Authorize Code grant flows.
Ask a new question if you have more questions on how to do this.
I have an app were there are 2 kinds of users.
A builder and an owner.
Now there is a centralized platform that I am building, were each builder who have their own docu sign account with them, will register. And then provide with a docusign URL (I am not sure what that is), and the owner then clicks on the link, once they are logged in to their part of the system. They sign the document using docusign and the builder gets the corresponding response in the centralized system.
Is this approach can be done using docusign? Or the working of this is completely different?
You're likely referring to embedded signing vs remote signing from what I understood from your description.
https://developers.docusign.com/docs/esign-rest-api/esign101/concepts/embedding/
In embedded signing, your app will take care of authenticating the users on DocuSign's behalf.
Yes. The Builders are the DocuSign senders. As you say, they have the DocuSign accounts that will be integrated into your system.
The owners are DocuSign recipients. More specifically Signer Recipients.
The owners do not sign into DocuSign at all. They may register (and login) themselves with your app, that's a different issue.
When appropriate, the owners click a link on your app to sign documents.
You then have some options: did the builder initiate a signing request for the owner to sign at some point in the future? Or is the signing request initiated when the owner decides that they want a document generated that they will then sign? (Or both?)
When it comes time for signing, if the signing ceremony is presented by your app to the owner, we call that embedded signing.
If the builder initiates a document to be signed by the owner, then the quickest technique is to immediately send a signing request (by email or SMS) directly to the owner. That's called remote signing by DocuSign. (The other way to do it is to wait until the next time the owner logs into your app. I would not recommend this since it would tend to slow down the completion of the signing process.)
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.
A 3rd party website is offering our service to their members. When they sign up, members have to agree to contract which comprises of a section from 3rd party and one section of our organisation. We want to streamline this process allowing us to control the template which is being used by 3rd party.
We want to control a part of envelope, one template document of our organisation through our account, although this envelope would contain a template from their account as well.
Currently our agreement template is maintained on 3rd party account and any changes which are needed, we have to request them and they fail at incorporating them properly.
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 appropriate companies
Unfortunately I don't fully understand your question. Is the sender using the API to create the envelope?
An envelope is controlled by the sender. If you want to provide a document that will be used by someone else within an envelope, then I suggest that you set up a web service that will used by the sender to retrieve the signer-specific document from you.
The sender will then include your document in the envelope sent to the signer. Since your web service will supply the document, you'll be in control of your document, your part of the overall envelope that will be sent to the signer.
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.