Directions regarding handing Zoom Server-to-Server app

Hi there!
Our web app needs to be able to create and have concurrent meetings. We are planning to use the Server-to-Server OAuth approach. However, we’re having trouble navigating through the API docs and some of the flows for creating users and meetings via the APIs. Our main flow includes inviting users on our web app via email by creating a new Free/Licensed user on our Zoom One Pro account. When their account is verified, our Server-to-Server OAuth app will make API calls to get their user tokens to create meetings and start them.

To test this flow, we tried creating a meeting with the owner / main user’s account (which is a Licensed account), however, when we tried to create an instant meeting with their account, we receive a 404 error with message “Request failed with status code 404”.

Here are the steps we followed:

  1. Created a Server-to-Server OAuth app.
  2. Collected the Client ID, Client Secret and the Account ID from the app after activating it.
  3. Get the user’s access token from POST /oauth/token endpoint using the above three keys
  4. Using the access token, hit the endpoint POST /users/{userId}/meetings with the payload given below to create an instant meeting. The userId of the main account owner was passed in the path parameter.
topic: 'Discussion about something',
agenda: 'Lets discuss',
type: 1,
settings: { 
  host_video: false, 
  participant_video: true

The response gave us 404. We’re a bit stumped about what’s going wrong and we’d appreciate your help.
Thank you!

According to the Create a meeting API, the 404 response status indicates that the user wasn’t found. Can you check whether the user ID you’re using appears in the List users API?

Hello @MultiplayerSession, yes I checked the List users API, and I indeed found that the user is being returned with the API response, with:

  • verified: 1
  • type: 2
  • status: “active”
  • role_id: “0”

What might be causing the 404 in this case?

Sounds like you were able to get other API responses, so the URL to the API endpoint sounds correct (the token endpoint and all the other API endpoints are on different domains and root subdirectories). I’d check if you’ve granted the meeting:write:admin scope and see if there’s anything in the API Call Logs. There was a recent change to scopes in that the user that owns the app needs at least the same privileges that the app needs (the option to transfer the app to another user disappeared in what I assume is an attempt to help encourage this), and changing the owning user’s role will cause removed scopes to be dropped from the app as well.

1 Like

Thank you for your suggestion and insight @MultiplayerSession!

@sowmen Have you verified the correct permission was granted to hit the API endpoint?

Hello @donte.zoom, I have verified the scopes have been assigned properly. Before I call the Create meeting API, I request a new access_token for the admin user, and the scopes assigned for this user are:

token_type: 'bearer',
expires_in: 3599,
scope: 'account:master account:read:admin account:write:admin meeting:master meeting:read:admin meeting:write:admin meeting_token:read:admin:live_streaming user:master user:read:admin user:write:admin'

Below is the list of scopes granted by the server-to-server OAuth app:

  • account:master
  • account:read:admin
  • account:write:admin
  • meeting:master
  • meeting:read:admin
  • meeting:write:admin
  • user:master
  • user:read:admin
  • user:write:admin
  • meeting_token:read:admin:live_streaming

It looks like you have the correct permissions. Are you only seeing this behavior when testing with the userId of the main account owner? Just tested on my end and the following payload returned a 201 response:

"topic": "Discussion about something",
"agenda": "Lets discuss",
"type": 1,
"settings": { 
  "host_video": false, 
  "participant_video": true

What happens if you test with another user in your account?

Hi @donte.zoom @MultiplayerSession the issue has been resolved and the APIs are all working now properly! It turns out my auth header was missing the Bearer keyword before the access token.

Thank you for your support!

1 Like

Wonderful @sowmen! Glad to hear the issue is now resolved – happy coding!

1 Like