I have 1700 users who have registered to DocuSign using the company domain. These users are not part of the account. I am looking for an API to get more information on these users such as when they last logged in. I see there is an API available for getting users that are part of the ACCOUNT.
Users: List
GET /v2/accounts/{accountId}/users
As people who directly registered with my company domain email address don't have an account, I am not able to use this API. Let me know if there is any other API to get this information.
There's no API that will give you this information. I'd suggest that you contact DocuSign support (or ask your DocuSign Sales Rep, if you've been working with one) for assistance -- it may be possible for them to provide this type of information for you.
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/
When using ‘https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=92e53xxx9-4xxxxxxxxxxxxxxxx2f893&redirect_uri=xxxxx’, after logging in to Docusign Account and obtaining AccessToken, calling CreateEnvelopes API returns the error'The specified User is not a member of the specified Account.'
[add User][1]
[1]: https://i.stack.imgur.com/jEWFv.png
I found that this User must be added in the User module before it can be used. For users who already have a Docusign account and they have paid for it, do they have to invite it? If an invitation is also required, how is the fee calculated?
What we need now is that users already have their own Docusign accounts and have paid for them. We help with the integration. The expenses are also directly deducted from their own Docusign accounts.
Many potential issues here.
First, When you call CreateEnvelopes API you need to provide an accountId (GUID) in the URL. That has to match the right account that you plan to use.
Second, you have account-d.docusign.com which is the developer env, but you are talking about
users who already have a Docusign account and they have paid for it
That suggests a production account, which is account.docusign.com
You should also check the baseURI that you make API calls to, is that demo.docusign.net or something in production?
Generally speaking, a user must be a member of the account where you make API calls and the user is determined based on the authentication. However, users can be members of more than one account, so that's another potential wrinkle here.
If an invitation is also required, how is the fee calculated?
Odd question for a developer forum, but yes, some accounts in production charge by seats, which means that if you have more users - you may get charged more, you will have to contact DocuSign Sales for details on your specific account plan and pricing.
Simply looking for some direction, whether it's a link to the docs or an example:
I want to use Passport to authenticate users using Slack/Passport but only if they belong to my company. So, for example,
olaf#mycompany can log in and view protected assets
ishtar#anotherco cannot do either, despite having an account with slack
A cursory search found this issue but I couldn't find anything in the docs.
Thanks!
Slack Passport is using the Sign in with Slack feature. It requires users to already have an existing Slack account for your Slack workspace.
So to ensure that only users belonging to your company get access to your web site all you need to do is verify that you receive an access token for the right Slack workspace, e.g. the one of your company. You can check that by comparing the team_id in the access token.
Apparently you can pass a team parameter during the oauth flow as described here. This allows slack to do the id comparison on their end, but it does require the developer to know what their team's id is ahead of time.
I am trying to use DocuSign in my app, it’s really an excellent tool, however, I've met some problems and hope you could help me with
it, thanks.
First of all, let me explain my scenario, let’s say Annie who are using my app, Annie opens a document in the app, she generate a digital
signature of her own on the document, then she shares the document to Tom and invite Tom to sign his name on the document.
I leveraged DocuSign Api with the following step to complete the above scenario:
For each document user opened, create an envelope
Open console/sender view in embedded h5 view
User will sign his/her name and edit it in embedded view
My questions are:
·User needs to have a DocuSign account to use console/sender view, but Annie or Tom don’t have an account and may not would like to register a DocuSign account in the app.
Is it possible for me to create an account for Annie through some kind of Api?
· Even if they already have valid accounts, Annie signs her name on the document, when she wants to invite Tom to sign on the document on a certain place, she have no way to find Tom on the page she edited as DocuSign do not know Tom and I could not add Tom’s information on the page.
Is there any kind of method that I can show Annie’s contacts on the page and let Annie to select any contact on it?
My questions are:
User needs to have a DocuSign account to use console/sender view, but Annie or Tom don’t have an account and may not would like to register a DocuSign account in the app.
The sender of the signing request needs an account. The sender can be either a "system" account (your application) or a human. Often a human's account is used, that way he or she will receive back information about the signing progress, will see the signed document stored in DocuSign, etc.
Is it possible for me to create an account for Annie through some kind of Api?
Yes, your app (and your account) can be enabled to use the API to provision new sender accounts. These accounts cost money, so in this case, your company is reselling DocuSign services to your end customers. DocuSign is happy to work with you to enable this.
Even if they already have valid accounts, Annie signs her name on the document, when she wants to invite Tom to sign on the document on a certain place, she have no way to find Tom on the page she edited as DocuSign do not know Tom and I could not add Tom’s information on the page.
Is there any kind of method that I can show Annie’s contacts on the page and let Annie to select any contact on it?
If your app is creating the envelope via the API, then your app can show Annie a list of recipients and let Annie pick Tom via your app. Then your app creates the envelope/transaction/signing request in DocuSign, including Annie and Tom as signers.
Then, via the Sender View, Annie can see the document before it is sent. Your app can do more than just add Tom as a signer: your app can add the "tabs" that control where Tom will sign, initial, and make other updates to the signed doc.
DocuSign DTM is a large system, so there is often "more than one way to do it." Please ask additional questions by opening new questions on Stack Overflow.
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