I will post it for the first time.
I am using the REST API in ZOOM.
From 22:00 on May 14th in JST, When using the user created with [custCreate] and accessing [start_url] with host privilege, there is a problem that will be redirected to [join_url].
As a result, the host state of ZOOM can not be established and the meeting may not be able to be made.
Also, once that user is redirected to [join_url], it seems that it will be impossible to start the meeting as a host after that.
For this trouble, I checked the log of the browser and confirmed what is happening. From the beginning of April when I began using REST API until 21:00 JST on May 14th, this kind of obstacle did not occur, but as mentioned above, it started to occur after 22:00 JST, We have not improved it now.
It does not necessarily mean that failure will occur for all users. As far as I see the database and the problem reports from the customers, I feel that the failure has occurred about 1/3 of the users created by [custCreate].
It is helpful to tell me what problems are occurring or what we should check or improve.
Hi Masashi,
The errors are due to an emergency fix we had to make with changing the start url zpk parameter to zak in the create meeting API. The start_url now expires after two hours, so the url will change to join as an attendee instead of host.
We’re working on a fix right now for our May release.
Thanks
Michael
Hi Michael,
Thanks for your reply. It was very helpful.
Finally I got to understand the problem we have been faced this past week.
So I have some questions.
- According to what you explained, Is it a bug that the [start_url] expires in 2 hours after creating the meeting or a specification?
Then, in the case of a service that reserves the start time in Zoom in advance, after 2 hours of reservation, the [start_url] becomes invalid and the meeting room can not be made.
Is it OK with that understanding?
- In your story I will fix it in May release, but is it OK with my understanding that it will be fixed within a week?
( We need to explain the prospect of Zoom’s modification timing for customers. )
- We are already using the Zoom API to operate the service, but is it OK to understand that our system itself does not need to be modified?
Hi Michael,
I have been waiting for your update for the last few days
After all, I confirmed that it was not fixed even in the maintenance release done this weekend.
https://support.zoom.us/hc/en-us/sections/201214205
I also read this topic.
“ANNOUNCEMENT: MAY RELEASE”
> we have to limit the expire time to two hours but since
> this is breaking the current flow of our customers
> we are looking to extended the expire time for
> the ZAK parameter to 90 days during our May Release."
The fixes you mentioned here are not working yet.
If it is true that you make corrections, Zoom’s obstacles that bother me will be resolved, but it is not clear what time it will be modified. When will this be fixed?
I am very troubled, please announce it officially.
It is not good that every two weeks of ERROR continues, and inquiries to that matter are not followed properly.
Hi Masashi,
We’re sorry for the inconvenience with this issue and the miscommunication. The changes will actually be released around June 16th timeframe. In addition to your question, yes you are correct, it is a bug and the [start_url] expires after 2 hours after creating the meeting and the meeting is launched by the attendee and not the host. Also, your system does not need to be modified as the changed need to be done on our backend.
Hi Michael,
I get the point that the renewal version will be released from your company on 16th June.
Certainly, even if the connection of one ZOOM succeeds, it is rarely reported that the connection relationship between [client - host] isreversed, and I think that this is derived from this bug.
Since this obstacle has occurred, we are being scolded for a while by customers, so we hope that such obstacles will be corrected as soon as possible and at the same time.
arigatou.