Description
I am trying to update the host for an existing scheduled meeting via the Update API (PATCH). Our app uses JWT for authentication and from what I’ve read, this is possible by passing the new host in the “scheduled_for” parameter. When doing this, I get a 204 response (success) but the meeting host is unchanged. Regardless of what I pass as “scheduled_for” this is not working. Even passing non-existing account users/ fake users does not trigger an error but the host is never updated.
Thank you for reaching out to the Zoom Developer Forum. Please make sure that you meet the Prerequisites for scheduling meetings on behalf of another user and that the proper privileges have been assigned.
Thanks for the quick response. As far as I know we are meeting the prerequisites. We have over 300 licensed users under our account. Our application schedules and updates meetings using the API with a JWT token. So far every endpoint is working as expected for us. Even this update endpoint works for any other parameter but the “schedule_for”, which we are trying to use to update the host of an existing meeting. I understand that a user needs to assign the scheduling privilege to a second user so this second user can schedule on behalf of the first user. That works fine for us on the Zoom app/web interface. But we are trying to do this via the API, where we authenticate with a JWT token and as I understand it, once authenticated, we should be able to perform these updates. Please let me know if I’m missing something. Are you saying that we would need to somehow set that scheduling privilege for the account so we can change the host of meetings we are now able to schedule for all our users already thru the API anyway? Can you please clarify that?
Thank you for providing additional information. If you use the user ID instead of the email, does the request work as expected? If not, please send an email to developersupport@zoom.us with the exact endpoint, request body, and response that you’re seeing and I’ll investigate this further there.
In order to keep the solution to this issue public, I’ll update the thread with what we found. We saw that the parameter being passed was scheduled_for (past tense) when the actual parameter is schedule_for (present tense). After changing that parameter and configuring scheduling privileges, the issue was resolved.
