Error 500 for Plan Usage API

Format Your New Topic as Follows:

Get Plan Usage API returns code 500 and Site does not exist
Get Plan Usage

Description
Using Server-to-server OAuth, the API response is:

{
    "code": 500,
    "message": "com.saasbee.webapp.pbx.exception.PbxException: Site does not exist."
}

How To Reproduce
Steps to reproduce the behavior:
*1. Send a GET request to https://api.zoom.us/v2/accounts/me/plans/usage
*2. Server to Server OAuth with /account:read:admin scope
*3. The API responds with the error described

Hi @val.curada ,

This API endpoint is for Master Account users. Can you please confirm you are one?

We are using a sub account

Hi @gianni.zoom,
It is a sub-account, as mentioned by @rotabigue .
However, this has been working on our end before. We were able to read our usage in Zoom, even before Server-to-Server OAuth. Are there any changes in the API?

Thanks.

Hi @rotabigue @val.curada to confirm, are you the master account querying a subaccount id? If so, it should work. If you’re a subaccount trying to see your own usage, I do not believe it should work.

Please also confirm the querying user has the “manage the subaccount” role enabled.
image

The account that experiencing the issue is our sub account which was working until we encountered the issue last Thursday. We there any recent changes in the authentication? With the screenshot below, we are using a different email address to manage the master account.

Hi @rotabigue ,

Were you using a subaccount access token to query the endpoint for data about the subaccount? If yes, you’re saying you’ve been able to use it in this way up until this point?

Or were you using your master account access token to query the endpoint for data about the subaccount?

Can you please confirm this as well:

Were you using a subaccount access token to query the endpoint for data about the subaccount? If yes, you’re saying you’ve been able to use it in this way up until this point? - Yes that is correct

No, the role is for only the sub account.

Hi @rotabigue ,

Try adjusting to satisfy the following role provisioning, generate a new token and query again:

image

There may be a breaking change if it was previously working as is, but testing the role provisioning can help us isolate the root cause.