Yes, we are receiving the initial access and refresh tokens as expected. It is when we try to use that refresh token to perform the refresh that we are getting the error.

It’s certainly possible we are doing something wrong on our side (although as I mentioned we’ve read the docs and tried several approaches), but it’s a strange error and we couldn’t find any documentation on the returned error codes that might help us debug… if there’s any additional details I can provide that might help you debug on your side, please just let me know.

It appears to have solved our problem, so you may want to update the docs accordingly. Also on that page, the refresh token section makes reference to the revoke endpoint, which we noticed, but could be quite misleading for folks.

Also seeing this issue when trying to refresh an access token. The initial code/token exchange works, but after the access token expires we get this message when attempting a refresh. The docs are in a pretty bad state and contradict the OAuth2 spec in several ways.

Just to close the loop on this, apps created via the developer site seem to have very limited OAuth scopes that are not configurable. If you construct an app in their marketplace you can set your scopes which solves the problem.

Unfortunately the scopes are not documented anywhere, so it’s a bit trial and error to figure out which ones you need. For example, we found we had to request write access to users just to get a listing of users, which is both counter-intuitive and problematic from a security perspective – resulting in some questions from our customers. But at least it works now

Hey Craig, thanks for following up on that. My apologies, I meant to say that Michael’s example didn’t work.

We’ve created our app through the marketplace and still seeing this issue. We’re also having trouble with getting the scopes working in production, seeing errors like “Invalid scope: meeting:write as system can’t support! (4,700)”.

Can you share the curl command that you used when trying to get the refresh token? Below is the one that I just used and it worked on our end. Keep in mind that the clientID and client secret was for --user was from marketplace.

Hey Michael, thanks for jumping in. Playing around with this some more I was able to successfully refresh a token, so I’m going to assume I was doing something wrong before. I’ll suggest a few edits to the docs, but I would highly recommend having a developer look at them closely as there are simply a large number of typos and fat-finger bugs (e.g. grant_type=refresh instead of grant_type=refresh_token).

In regards to another issue we’re having, for our production client we are seeing “Invalid scope: meeting:write as system can’t support! (4,700)” when we redirect the agent to the authorization page. It’s the same URL as the dev equivalent (client ID and redirect URI being different), which does work. The only thing I can think of is that we haven’t actually been published on the marketplace. I sent the exact authorization URL I have been using to marketplace-support@zoom.us.

Thanks for letting us know about the error. We took a look and it’s happening because your production credentials are not live yet. You will need to create your publishable url in the marketplace before your app credentials and scopes to be valid.

On our end, we’ll make sure to update our marketplace site and documentation to explicitly state that production credentials and scopes cannot be used until there is a publishable url.

This page (https://devdocs.zoom.us/docs/oauth-with-zoom) does have an “example refresh request” but it’s incorrect as it uses authorization code as a parameter, not the refresh token, and it also specifies grant_type=refresh instead of grant_type=refresh_token.