very possible...can you make them a super admin and test it again?

He already was a Power User. I’ve updated his Power User Profile and I’m asking him to try again.

Then, we’ll try for SuperAdmin if we need.

Hey @JKolodner! Docebo leverages OAuth scopes and grants to allow access to the API, so the endpoints are following a role-based access model by default. You could look at expanding the permissions of the power user, to cover both the course, users, and reports area, or go full access with a Super admin user making the API calls.

You can emulate this in the Docebo API Browser while logged in as any level user and authenticating before making a call. If your permissions allow viewing, the results will indicate that. 

Good to know, thanks @John.

Working on it now.

For the API direct access, you always need to be a super admin, the only ways I have around this leverage the iframe widgets with advanced settings turned on, there is a token process you can exchange quickly for a usable API token, which can basically empower a standard user to use the API in the background. It’s one of my favorite tricks.

Hey @Bfarkas!

For the 7.0 API, you actually don’t have to be a Super admin to invoke it… you can see this in a small note within our KBA on authentication (“system requires specific user permission”):

If you consider the fact that the public API shown on API-Browser listings are used inside the product directly, users are calling these endpoints naturally as they navigate the platform’s UI. Here’s a short video to showcase a Power User calling the GET manage/v1/users endpoint.

While I wasn’t able to capture the token request in Chrome’s Developer tools window (it closes too fast to capture the request), it does make a call to a backend OAuth 2.0 app service that we use in order to login as your user and obtain a token.

Further, as another example one recommendation we make for clients implementing Flow is that they must implement a JWT authentication flow. This is key in order to determine which user should see the launcher and thus what data we show back (that they are configured to access based on all the normal administrative assignments you might make for courses, LPs, Catalogs, etc…).

I hope it helps. By all means I’m not a developer by trade but have seen some things so thought I’d share with the group!  

TBH, backtracking a bit, the comment/note in blue may indicate that the API-Browser’s backend must use a certain type of OAuth authentication flow to work. So, I read it as you “cannot simulate client credentials grant type in that type of authorization scenario/within the API-Browser experience.

For machine to machine authentication, client credentials authorization for OAuth 2.0 is what I see being most recommended. I found this article on Medium to be a good refresher on all the “options”. In addition, this conversation was an interesting one to read with a case considering PowerShell scripting, on behalf of another user, leveraging client credentials grant type..

@John I know I know, it’s the nuance, what I have found is when most people are talking about accessing the API though it is just the browser, or direct access postman which is usually(and easier to keep clear) just super admins, should have been clearer. That chrome token piece is in the realm of my iframe trick too, and yes it happens crazy fast! One of my fun things to try and demo to folks live!

So right and great points all around, as always, Brian!

DYK… there are also Course Additional Field & Enrollment Additional Field iFrames you could leverage to do “neat” (nerdy) things like you’ve mentioned (assuming you’re referring to the salt secret)? 

100% I’ve never had to actually go to production with the additional fields, but have played with them. I have often done the Course widgets though, customized inline support on every course page :)