Changing meeting hosts

API Endpoint(s) and/or Zoom API Event(s)
PATCH /meetings/{meetingId}

Description
I’m developing an application that interacts with Zoom via the published REST APIs. I’ve created a Server to Server OAuth app to generate a client ID and secret with which I’m able to authenticate. The app has the following scopes:

user:write:admin user:read:admin meeting:read:admin group:write:admin group:read:admin meeting:write:admin

I’m able to create meetings with POST /users/{userId}/meetings and change the configured alternative hosts with PATCH /meetings/{meetingId}.

However, I am NOT able to change the host of a meeting via PATCH /meetings/{meetingId}. Here is a sample request and response:

PATCH https:// api.zoom.us /v2/meetings/123456789
{ "schedule_for": "new_host @ email.com" }

Status: 400 Bad Request
{
"code": 3000,
"message": "You cannot schedule a meeting for new_host @ email.com"
}

The user that created the Server to Server OAuth app is api_user @ email.com. I have added this user as an assistant to the original host of the meeting (first_host @ email.com) AND to the new host (now_host@email.com). All 3 users are licensed users.

PS: I can create a meeting for new_host @ email.com using POST /users/new_host @ email.com/meetings but any attempt to change meeting hosts fails.

PPS: All the emails have a space around the @ like “new_host @ email.com” because as a new user I couldn’t post more than 2 links, but it should really be “new_host@email.com”. The URL in sample request also has spaces for the same reason.

Error?
400 Bad Request, code 3000, “You cannot schedule a meeting for new_host @ email.com

Hi @if_s37
Thanks for reaching out to the Zoom Developer Forum and welcome to our community, I am happy to help here!

That error that you are getting could be due to the issue that you have not enabled scheduling privileges to the user you are trying to work with, please take a look at this couple of support articles:

Let me know if this helps!
Elisa

Hi Elisa, thanks for responding. As I stated in my original post, the user making the API call to PATCH /meetings/{meetingId} is already registered as an assistant to both the original meeting host and the user that I am trying to make the new host.

Furthermore, the user making the API request is also able to make meetings for both of those users through POST /users/{userId}/meetings.

Make sure that both users have scheduling privileges and that way you will be able to schedule meetings for other users

The user making the API call already does have scheduling privileges.

When I check the registered assistants for both the current host and the new host using:
GET /user/{userId}/assistants
the API user is returned.

When I check which users the API user can schedule for using:
GET /users/me/schedulers
both the current host and the new host are listed.

And yet, when I call PATCH /meetings/{meetingId}, I get “You cannot schedule a meeting for new host”.

I was able to successfully change meeting hosts, but with a major caveat.

The user specified in the path of the original POST /users/{userId}/meetings request must be the one registered as an assistant to the new meeting host.

It doesn’t matter who is making the API call, or who the “schedule_for” value is when the meeting was originally created. The only thing that matters is the {userId} in the path.

In my case, I was creating a meeting via POST /users/{user who is the host}/meetings. But then {user who is the host} wasn’t registered as an assistant to the new meeting host, so my attempts to change the host failed, even though the user making the call to PATCH /meetings/{meetingId} WAS registered as an assistant.

This is unintuitive to say the least - please update the documentation to state this behavior explicitly.

For future readers, this is what I’m doing now, which works:

As the API user, which is registered as an assistant to all users:
POST /users/me/meetings { "schedule_for": "desired_meeting_host_email" }
PATCH /meetings/{meetingId} { "schedule_for": "new_meeting_host_email" }

Thanks for sharing your findings with the community @if_s37
I am happy to hear that you were able to troubleshoot this