"Update a webinar" endpoint's start_time changes are ignored if the webinar was scheduled to be currently running

Description
The “Update a webinar” endpoint (PATCH/webinars/{webinarId}) ignores changes to the start_time if the webinar is currently supposed to be running (even if it actually isn’t started). The endpoint returns an HTTP 204 status code, but the time doesn’t change upon inspection of the webinar on the Zoom web site, or via the “Get a webinar” endpoint (GET /webinars/{webinarId}).

If the webinar is supposed to begin in the future and the start_time is changed, the endpoint response is identical and the scheduling change is applied.

What restrictions are there for changing a webinar that is supposed to be underway, and how can this be detected and communicated to the user?

Error
There is no error message; the API logs show an HTTP 204 status code as if the changes were accepted (webinar IDs are masked):

{
"endpoint":  "https://api.zoom.us/v2/webinars/***********",
"response_headers": [
 "Set-Cookie: zm_aid=""; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly"
],
"date_time":  "2021-08-24 11:16:47",
"method":  "PATCH",
"request_body":  "{"type":9,"start_time":"2021-08-24T15:20:00Z","duration":15,"recurrence":{"type":3,"repeat_interval":3,"monthly_day":24,"end_times":1}}",
"response":  "N/A",
"request_headers": [
 "authorization: ******",
 "connection: close",
 "content-type: application/json; charset=utf-8"
],
"request_params": [
],
"http_status":  "204"
}

This is indistinguishable from a scheduling update to a future webinar that does end up applied (webinar IDs are masked):

{
"endpoint":  "https://api.zoom.us/v2/webinars/***********",
"response_headers": [
 "Set-Cookie: zm_aid=""; Domain=.zoom.us; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly"
],
"date_time":  "2021-08-24 11:31:19",
"method":  "PATCH",
"request_body":  "{"type":9,"start_time":"2021-08-25T08:00:00Z","duration":120,"recurrence":{"type":3,"repeat_interval":3,"monthly_day":25,"end_times":1}}",
"response":  "N/A",
"request_headers": [
 "authorization: ******",
 "connection: close",
 "content-type: application/json; charset=utf-8"
],
"request_params": [
],
"http_status":  "204"
}

Which App Type (OAuth / Chatbot / JWT / Webhook)?
This is a JWT app.

Which Endpoint/s?
The “Update a webinar” endpoint.

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Reschedule a webinar to begin a few minutes from the current time using the “Update a webinar” endpoint. See the “Error” section earlier for examples of the requests that are issued.
  2. Wait for the begin time to elapse, and before the end time is reached.
  3. Reschedule the same webinar to begin in the future using the “Update a webinar” endpoint. See the “Error” section earlier for examples of the requests that are issued, particularly the first request.
  4. Inspect the webinar using the Zoom web site as the webinar host and via the “Get a webinar endpoint”, and observe that the start_time field is still set to the time in step 1 instead of the new time indicated in step 3.

For comparison, rescheduling a future webinar applies the new time:

  1. Reschedule a webinar to begin a day later from the current time using the “Update a webinar” endpoint. See the “Error” section earlier for examples of the requests that are issued.
  2. Reschedule the same webinar to begin an additional hour later using the “Update a webinar” endpoint. See the “Error” section earlier for examples of the requests that are issued, particularly the second request.
  3. Inspect the webinar using the Zoom web site as the webinar host and via the “Get a webinar endpoint”, and observe that the start_time field is updated.

Screenshots (If applicable)
See the API Call Logs in the “Error” section earlier.

Additional context
The user scenario is originally scheduling the webinar at the incorrect time, then once the incorrect time is reached, realizing that the time should be corrected to an hour later, and trying to issue a correction.

Hey @MultiplayerSession,

Thank you for reporting this, I’ve reached out to our engineering team to see if they can confirm this as expected behavior. If so, I think we need to return something other than 204 in this case.

I’ll let you know what I hear. (ZOOM-302905)

Thanks,
Max

I’m also seeing the same behavior for the Update a meeting endpoint where if the meeting recently should have started and I try to adjust the start time to the near future (a couple minutes later), the call succeeds with status code 204 but is ignored and the meeting times are unchanged. If I set a far future start time (like the next day), the call still succeeds with status code 204 and is actually reflected.

If I visit the Zoom web site and interactively edit all occurrences for the meeting and adjust the start time in a similar manner, that is also reflected.

The documentation for the Update a meeting endpoint does state that “The start_time value must be a future date.” which seems like it’s being enforced very literally as a future day and not just a future time on the same day. If that’s the case and is intentional, can we get the exact heuristics clarified on what is considered to be the same date cutoff so I can detect this situation and inform the user, or decide if we are okay with spending double the rate limiting API budget and set it to a far future time and then immediately back to the intended value?