Requesting dashboard*:read:admin scopes

We would like to add functionality to our Zoom App to determine if the current user has an active meeting running.

I was advised to use this API for that purpose:
GET /metrics/meetings

It appears that this API requires the following scopes:
dashboard_meetings:read:admin, dashboard:read:admin

But it does not appear that I can add those scopes to my App currently?
Other solutions have proposed creating a new app but we don’t want to do that as we already have users on our current app.

How can we add those scopes without creating a new app?

Thanks!

For the user that owns the app, make sure that user has a role that has permission to view the equivalent information through the Zoom user interface. As an account owner, go to User Management’s Roles, pick the role to edit, then in the Dashboard section, mark the checkboxes you need (most likely Meetings and Webinars, as that’s what we’re using). Note that the app owner user needs to maintain these permissions on an ongoing basis.

You used to be able to look up the user interface checkboxes for already-added scopes by visiting https://marketplace.zoom.us/apphelp/<appID> where <appID> is the application ID from URLs in the Manage section, but that page seems to have broken recently.

Hey @MultiplayerSession thanks for the reply.

Those settings are all set correctly for the user that owns the app. It still does not result in a token generated for the app presumably b/c the scopes are not present at the app level.

Just in case it wasnt clear this is an app that is on the Marketplace, so the user in question will not be one that we can control.

It hasn’t been my experience so far that the app owner user’s permission change what scopes a token can request.

The issue that I am seeing is that the app is not allowing me to request these scopes. This feels like either a distinct desiccation to disallow app tokens to access this API or feature/scope selection for these scopes are not listed for some other reason that I am trying to understand.

Here’s a picture showing what I mean, the app cannot request token scopes for dashboard*.

What is shown on the Created Apps page in the “Type” column for your application? The :admin scopes need “Admin Managed” or “Account Level” to grant them, and since “Local Test” requires the application’s owner to be able to approve of those scopes, the application owner’s role needs to be able to do the equivalent activities through the Zoom user interface (outside of the application).

To use those scopes, you’ll need to use an account-level app. However, only user-managed apps currently support meetings. For some APIs, you can use Shared Access Permissions but the dashboard APIs are not one of them.

With Zoom Apps, the only way to check if a user is in a meeting is by using the runningContext and getRunningContext function while your app is open in a meeting. However, this won’t work for meetings where the user has not opened your app.

Alternatively, you can subscribe to webhooks and keep track of the meeting.started and meeting.ended events for the user.

Can I ask the use case for checking if a user is in a meeting?

Okay that makes more sense @MaxM and @MultiplayerSession, I understand better now that this has to do with the fact that we created a User-managed App vs. and Admin-managed.

@MaxM, Our use case is that we have an app that will behave as a bot, join a meeting, and generate content for the user based on the meeting.

In our app’s web interface, we would like the ability to detect that a meeting is running and give them the option to start a bot for that running meeting.

Perhaps webhooks are the right approach there? Given the use case, what would you advise @MaxM ?

Thanks!

@MaxM Wanted to check in and see if you could advise on the right approach :pray:

Bump @MaxM

Would love insight from you or anyone might know the recommended approach. :pray:

@MaxM This is still important to us. Can we get the recommended approach here?

@gibron I do think the user-level webhooks are your best bet here. The path to get the user-level app adopted alongside the account-level dashboard app would be too much friction.

What you’re looking for is a user-level check on whether the user is in a meeting; what if you used the user presence status API?

This would require the user:read

This wouldn’t be 100% fool-proof perfect… A user could join a Meeting and then change their status to “Do not disturb”, for example. But this seems to me to be a much better option than the account-level dashboard API and it wouldn’t require you to store/reconcile the webhook events.

You’d want to treat Presenting and In a Zoom Meeting as the same “in-meeting” status.

For the user who owns the app, all of those settings are appropriately configured. Presumably because the scopes are absent at the app level, it still does not result in a token being issued for the app.

In case it wasn’t evident, the user in issue will not be under our control because this is an app that is available on the Marketplace.

According to my observations thus far, a token’s ability to request different scopes is not dependent on the app owner user’s authorization.

@bakihanma5333 If your application is properly configured at the marketplace level there shouldn’t be an instance where you would need to request different scopes at run time.

Can you expand on the issue that you’re encountering?

Cool @michael.zoom thanks for the reply.

As I understand it, the /users/{userId}/presence_status would not give us the meeting id though right?

Is there a way to get the meeting id that is this straightforward?

We want to give the user the ability to launch the bot for the specific meeting they are in from our webapp.

Will dashboard APIs ever be added to user-managed apps? My plan was to calculate data usage from the Get meeting participant QoS API. Is there another way to get bitrate?

Hey @amgregory , the scopes for this endpoint is only available for an account/admin-level app.

We are working on ways an app can get optional/progressive scopes given a user’s permissions; however, the user will always need the account-level role permission to view Dashboards.