Changing the scheduled host for an existing meeting using the update_meeting API?

We have a use case where a large number of meetings have already been created with scheduled hosts. It turns out that we really want one of the alternative hosts to be the Zoom host to free up the Meeting Host to facilitate. At this point we have two options:

  1. Regenerate all the meetings, redistribute the links and update the contents of a table or
  2. Use the update_meeting PATCH api to change the schedule_for to the new host

The issue I’m running into is that I am attempting to run an experiment updating these two fields:

body = {
  schedule_for: 'was.alternate@westat.com',
  settings: {
    alternative_hosts: 'was.host@westat.com'
  }
}

Then calling meetings/${meeting_id} passing the body. Note that I do have schedule privileges for this user.

I am getting the following error:

400

{
       "code" => 3000,
    "message" => "You cannot schedule a meeting for was.alternate@westat.com."
}

Is what I am attempting impossible?

Hi @johnelrick,

Thanks for reaching out about this—you’re essentially trying to swap the current host and alternative host, is that right?

Can you confirm that both users are licensed?

Thanks,
Will

Yes, both are licensed.

Thanks for confirming @johnelrick. Can I kindly ask that you share the full request (including the actual emails of the host and alternative host) with us by opening a ticket here? This will help us to debug.

Thanks,
Will

Before I enter a full ticket, except for the obfuscated emails that is my full request. I assumed the API would update only the fields passed in and leave the others intact. If that’s not the case, then I should attempt it with a full replacement (which will require additional coding to retrieve the full existing meeting information and then do a an update).
Is that how the process works? The documentation is a bit unclear as to what is required on an update call vs optional.

Hi @johnelrick,

I do believe what you’re trying to do here should be possible—I see that you’ve already written in directly, and I’ve just replied back to you via email. I’ll continue the conversation there.

Thanks,
Will

Will, have to bump this. I need a solution ASAP or I have to regenerate all the meetings.

Hi @johnelrick,

Please see my latest reply to your email.

Thank you,
Will

Getting same error while update meeting using PATCH method to change Existing host to New Host,

{“code”:3000,“message”:“You cannot schedule a meeting for .xx-user-id-xx.”}

If you are not allowing to change hosting for existing created meeting using field “schedule_for” field then why field schedule_for has been given for updation request ?

It very confusing that field is given to change host for existing meeting and its not working properly.

Getting same error while update meeting using PATCH method to change Existing host to New Host,

{“code”:3000,“message”:“You cannot schedule a meeting for .xx-user-id-xx.”}

If you are not allowing to change hosting for existing created meeting using field “schedule_for” field then why field schedule_for has been given for updation request ?

It very confusing that field is given to change host for existing meeting and its not working properly.

Its giving same error for licensed users and free users. Not working at all

Why there is concept of user/host/email address in Zoom architecture for creation of meeting.?

Simply allow to create as many meetings but allow to start no of meetings which are Licensed / or as Per Configuration.

Just like other meeting provider, will simple create meetings allow to start or join (Gmail, Jitsi, and Others many more)

Why to create meeting inside perticular host /user ? just allow to create meeting direct…

My issue was that I was attempting to swap a host for an alternate in one step. It doesn’t work. What does is the following:

Step 1. Save the alternate hosts and PATCH to clear

{
settings: {
alternative_hosts: ‘’
}
}

Step 2. Update the host for the new host email or id

{
schedule_for: new_host
}

Step 3. Modify the alternate hosts to ensure the new host is removed from the list and then PATCH

{
settings: {
alternative_hosts: new_list_without_new_host
}
}

You must have schedule privileges for the new host and the alternates or you’ll get an error at that step.

Hope that helps.

1 Like

Thanks for sharing your solution, @johnelrick!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.