I have some doubts regarding the custom connector we are trying to build for docusign : -
Regarding the license plan that need to be bought by the customers who will be granting access for our connector to collect data from their docusign organization account. I am looking at the link https://www.docusign.com/products-and-pricing. API access support is mentioned in only the advanced solution. So I was wondering whether only we need to have "Advanced solutions plan with APIs support" plan or all our customers need to API access support in order to fetch their data.
As per the documentation, to make the REST API calls we need two fields 'base_uri' and 'account_id' (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints). Now, the response of userInfo API call gives an array of accounts and its respective fields. My doubt is, if multiple authenticated users (more than one accounts) are returned in this array but all are part of same organization, will they all have different account_ids. Main concern here is, will there be several Base Paths (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints#form-your-base-path) to make API calls?
2a. Further question is, what is the significance of 'is_default' field?
Is this related to main account (if is_default is true) using which we will create our Base Path?
Since this is a tech/engineering forum I'm going to answer only question #2 as question #1 is more of a business/sales question.
The reason you may get multiple accounts is that an authenticated user in DocuSign can be a member of multiple accounts. That said, it's the same user. Meaning, say foobar#blah.com has an account 123 with company X and account 456 with his school, then it's possible that when foobar#blah.com authenticates (With the same password!) to DocuSign we have a list of accounts associated with that user. We give you all of them when you make the API call. The default one is the main one that you would see when you log into our web app. You can decide yourself as the user which one is the default. Users who log into our web-app then see an option at the top-right to change accounts.
and yes, every API call is associated with a specific account. So when you construct the urls for your API - you do need to know which account for this user you are making the API call for. Your application can decide how to handle this.
Hope this helps.
Related
I have a question regarding base URI with user and account objects in REST API.
To summarize:
one user can have multiple account attached,
one account is attached to one company,
without OAuth, we can get base URI by calling API /login_information,
with OAuth, we can get base URL by calling API /oauth/userinfo
Is it right ?
If yes, can we say that one base URI is attached to one account and will be the same for every user attached to this account ?
In addition, is it possible to get base URI by calling an endpoint dedicated to the account, and not the user ?
Thanks in advance for your answer.
Everything you write is correct, you understand this pretty well.
The reason you cannot use an account API endpoint to find the baseUrl is the architecture of how this works. The DocuSign code is deployed to many data-centers, but it's the same code. The same APIs run on na2, eu1, au etc. etc. So they are not aware directly that they have a different baseUri than other data centers.
The OAuth endpoints are different/separate and can get information from all data centers.
OAuth is always about a specific user, because you cannot login directly to an account, but you have your own user that you use. An account is shared, but each user has their own password.
The only way to do something remotely similar to what you're asking is if you use the DocuSign organization feature.
You can then use the DocuSign Admin API to obtain information about the organization and the accounts in it. That information includes a siteId that tells you if it's on na1, na2, eu1 etc. Using that you can construct the baseURI.
Lots of limitations to this, so not sure that would help you.
I am using Azure API Management to proxy requests from Internet to our backend systems. I have a Product entry on Azure Portal and an API entry associated with the product. Generally access to the API must be by subscription, but I would like the method returning OpenAPI specification (as well as probably few other methods) to be accessible without subscription (freely).
I see "Requires subscription" checkbox on the Product level as well as on API level, but not on a method's level. So I need either:
bypass subscription check for certain methods while keeping access by subscription for others, or:
same but vice versa: keep the access free for API, but enforce subscription check for certain methods (not preferable, as this fraction is greater).
I checked the list of policies and did not find anything applicable for my case. Moreover this link states:
Subscriptions can be associated with various scopes: product, all
APIs, or an individual API.
Is there a way I can workaround this limitation?
I mean that, maybe you wanna some of the methods(less amount) in an Api can be called without a subscription while the left need. And I searched the ms document but failed to find such policy.
The link you provided also intended that. From my point of view,
how about trying to add a separated Api containing those methods that
don't need subscription?
We are using the CalendarView endpoint to retrieve a users appointments for a specific time period. While calling the endpoint we are passing $select=start,end,showAs to only retrieve the fields that we are interested in.
Our end client is concerned that even though we are filtering the results on our side we still have access to Calendars.Read and technically have access to read meeting subjects, etc. Is there any way in Office365 or the Graph API that our end client can apply more granular permissions to filter which fields we have access to?
Today Microsoft Graph application permissions give your application full access to the entity they cover (all the properties)/the endpoint (all the payload).
There's is no way to restrict access to specific properties of an entity for a specific application.
You can always suggest this idea on uservoice.
As mentioned on the link https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-code-grant, there are three access scopes DocuSign allows to fetch user's data : signature, extended and impersonation.
I am looking for a scope which allows me only read access. I need to build a dashboard of various activities/updates (getting the status of all envelopes, etc) of all the users of DocuSign at my company.
As per my understanding, I need 'signature' permissions/scope at-least as described under heading "Admin consent for internal applications" on https://developers.docusign.com/esign-rest-api/guides/authentication/obtaining-consent.
This means I will have access to create and delete the envelopes as well. Couldn't understand the 'extended' scope as well (as per my reading, it is helping to extend the access tokens validity and usage of refresh token any number of times).
Is their any other permission type (read scope only) that I can use based on my criteria?
Re read only scope. Not at this time. And since you want stats for all users' envelopes, you'll need Account Wide Rights. Full Admin is not necessary.
Perhaps an alternative might be to use the connect webhook system, and then track statistics as your app receives each notification message about changes to the users' envelopes.
I'm making an app that authenticates a coach with KA's API, in order to present statistics and reports on the progress of each student.
How do I see "For whom am I a coach" (inverse of /api/v1/user.coaches)?
or otherwise request user and progress data for all my students?
You can request /api/v1/user/students to get a list of the currently authenticated users' students. Note that this is an undocumented endpoint, not sure if that's on purpose or not, but I suspect just an oversight because IIRC I've seen them reference it on github issues in the past.
I added that endpoint to the khan npm module in this PR: https://github.com/weo-edu/khan/pull/4
An important caveat to note is that as of this writing, you won't be able to request students on behalf of a user who has authenticated your application, only the user who created the app you're currently using.
Put another way: If I create an application called "hello" while logged in as "Jeffrey", I can get all of Jeffrey's students by authenticating with the "hello" app. However, If I log in as Lisa via the "hello" app (via oauth, e.g. passport-khan), I'll have an access token but the Khan API will refuse my request because Lisa did not create the "hello" app.
This behavior is documented (albeit a bit confusingly) in this wiki page, here's the relevant paragraph:
It is recommended that schools have one teacher/coach account that registers for an API key. This enables a situation where the logged-in user is the same as the third-party developer, who then can access their own students' data pursuant to Khan Academy's "coach" relationship. For example, suppose the principal of Riverdale High wished to export data for multiple students via the API. The principal would create a teacher/coach account, perhaps called "RiverdaleHighAPI," and register for an API key. The principal would then ask all students of Riverdale High to add "RiverdaleHighAPI" as a coach, either directly or via several class codes. When accessing the API with "RiverdaleHighAPI" as the logged in user, the principal would be able to access the data for all students that have added "RiverdaleHighAPI" as a coach. The app would not have access to any other coaches' student data, even if another coach logged in through the app. To protect student privacy, we do not allow indirect consent through the coach, and we require each student to explicitly grant permission to access their data. Please note that we are working to improve this functionality; for the time being, this "RiverdaleHighAPI" account should only be used by the school's API client, not by any actual teacher or coach.
Lastly, khan actually encourages public use of their internal API. They recommend opening up your developer console while logged in to khan and looking for the endpoints that return the data you want. (see this note on their authentication document).
This is obviously a fairly non-standard practice and I assume the endpoints would be subject to breaking changes without warning. Also you'll be flying documentation free. That said, this approach may be the most robust option for your purposes. Here's the quote from their wiki for posterity:
The API explorer documents our public API, which has URLs starting with /api/v1, but unfortunately it's not very well-maintained and lacking in a few areas.
If you're feeling adventurous, though, you're welcome to use any internal undocumented API endpoints. For example, if you load a Khan Academy video page and use your browser's developer tools to look at the ajax requests being sent, you'll see that it gets a URL like /api/internal/videos/aubZU0iWtgI/transcript, which contains a JSON response with the video subtitles. That "internal" in the name means that we don't provide documentation, and we may remove the endpoint or change the format in the future, but you're welcome to use any internal endpoints if you keep those caveats in mind.