I am trying to figure out the best possible way to manage a system where we will be sending out different documents via the api through one account. These documents will need to be handled by different departments. Is there a way in the api to share the envelope with a particular group/user? My other idea was to create multiple department API users and depending on which document I am sending will use that departments API user and associate that API user with the department user. It seems like a more complex solution but I know it would work.
Thanks,
Dan
I'm not sure why your question was downvoted without a reason, so I'll throw out my 2cents.
Question 1: Is there a way in the api to share the envelope with a particular group/user?
You can share all of a user's envelopes with group/user, but not specific envelopes. I do not suggest building a workflow around this.
Idea 2: Create multiple department API users and depending on which document I am sending will use that departments API user and associate that API user with the department user.
This is the best solution for scalability and customizibility, remember that an API user does not need to be an admin to create an envelope. In this case, it would be better if that user was not an admin, so they are limited to access only the envelopes that you'd want them to access.
I'm not sure what language your integration is in, but you should be able to store all of the credentials in an array/hash and just call the specific entry for username/password per workflow.
You didn't post what requirements you need for these workflows, so this is a very high level generic question and answer. You may want to go back to the drawing table and figure out your hard requirements. The solution above may not fit all of your requirements, especially if your security team has specific requirements that they need to have followed.
example requirements
Envelopes need to be created through the API
All envelopes must reside on the same account
Envelopes can't be seen by other departments
Envelopes need to be modified by department DepartmentName after Envelope Creation
The API needs access to view the status of these documents
Related
First of all, I apologize for eventual noob questions, we are very new to the DocuSign API and are currently trying to wrap our heads around which is the most correct way of accessing the API.
I will start with an overview of our use case. We recently purchased a DocuSign prod. Account with an Organization enabled.
We have a Partner which uses a CMS Tooling which integrates with said DocuSign Account. This Tool allows for the Backoffice to create envelopes with documents inside and a url which leads to the signin ceremony through the Templates that we create inside the DocuSign Account. This url is afterwards send to the customer for them to sign the documents in the envelope. This Part is working and is currently being used.
Now what we want to achieve on our side, we have a nextJS web-app which allows the same customers (Which are the receivers of the created envelopes in the step above, same e-mail in both steps) to sign-in our web-app. We want to show the customer in a dashboard, if there are envelopes for him open that he can sign and if this is the case we want to show him the url which leads to the signin ceremony.
We were able to see that as soon as an envelope for a certain User is created through the CMS Tooling, we can see that envelope in our DocuSign Prod Account.
Now our thought process was, to show our customer his open envelopes, we just fetch all open envelopes in our DocuSign Account which match the customers E-Mail.
Is there anything wrong with this process or are we overlooking something?
And if it is okay to proceed this way which of the OAuth Flows is the correct one to use for this case?
From my understanding, the JWT Flow seems like the most reasonable one? Since the Customers that need to sign the documents, will not have any DocuSign accounts.
What have you tried to solve the issue?
We tried using the direct API Access, which worked when set up correctly but since we didn't have a OAuth Flow in place the Access token is only valid for restricted amount of time obviously and has to be refreshed. Hence we have to think first about how to grant access correctly
I would love to hear, what the right approach would be to achieve our desired result.
Once again Apologies for this kind of question, just trying to have a better understanding before we start building :)
Best regards!
According to the use case you mentioned using JWT Grant is fine as users of your integration will use a single system account to log in, you should use JWT Grant.
I would recommend going with the below link to know more regards different use cases and check the knowledge
https://developers.docusign.com/platform/auth/choose/
https://developers.docusign.com/platform/auth/oauth2-requirements-migration/
Question??? My company is using docusign for esignatures and we have run into a situation were we need to have the signed copies of the documents without the copy view watermark on them. To remove them we have turned to a site called eoriginal which will clean up the docs and remove the cope view watermark, however we are continuing to have numerous issues with this service. So I am attempting to find an alternative solution, any feedback or suggestions are much appreciated.
Not knowing what your issues are, I'm not sure I can help, but have you looked at our dev center article about how to export authoritative copy using the DocuSign eSignature SOAP API? It covers this topic in details and explains that you can do this given the following prerequisits:
You must use the SOAP API
Your account must have access to the
Authoritative Copy feature. Contact DocuSign Customer Support and ask
that your API user be granted permission to export Authoritative
Copies.
If you want to select which envelopes will record an
Authoritative Copy, add "authoritativeCopy": "true" to the envelope
definition in your API call.
If you want all envelopes to use
Authoritative Copy, ask DocuSign Customer Support to set the "Auto
Authoritative Copy:" to Enabled on your account.
Finally, it's important to note this is a one-time action, and once it is done - you can never do it again (for a given envelope).
I am trying to create a functionality using the Stripe API (not Stripe Connect) to let users add customers. If I understand this correctly, all customers will be added to my Stripe account. Is there a way I can distinguish which user added which customer, so that I can list all customers under one specific user?
I know Stripe Connect solves this problem, but it's not appropriate for my use case.
Thanks in advance.
About the only way you'll be able to do this - beyond tracking it in your own application's database, which you should definitely do - is to add Metadata to the Customers.
That said, you may want to reach out to Support and have them confirm that your use case makes sense; they may also have an alternative suggestion for you.
As #floatingLomas said, you can use the metadata field to store user info when creating a new customer (https://stripe.com/docs/api/customers/create), but as far as I know there's no specific API call to retrieve customers by metadata.
I mean, if your concern is to know who created a specific customer, it will be enough to retrieve that specific customer and look at its metadata field, but if you're looking for a solution which allow you to find all the customers added by a specific user, then I would suggest to create in your app a database table which keep track of that and do your searches through that.
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 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