Zak token issue: Host unable to start meeting

This was a support ticket before they kicked us out after two weeks of troubleshooting because dev support is only provided here. Ticket #16974601 has all the relevant details including exact tokens and meeting info.

We have had multiple instances the past couple of weeks of meeting hosts unable to start meetings using the original StartUrl generated when the meeting was created. When using the StartUrl, the host is asked to log in to start the meeting. This start url is stored on our end at the time of meeting creation. In this case, a couple days before the meeting.

These hosts are users generated with a custCreate action, so they cannot log in to zoom and only have access to the meeting provided by us through the start url. Additionally, the Zak token does not expire for 90 days, and is valid at the time of the meeting by several months.

We’re trying to figure out why the StartUrl is behaving this way. It is extremely disruptive when a host attempts to start a pre-scheduled meeting, only for the start url to not work.

Please let me know if there is additional info that needs to be provided. Thanks!

Has this been seen? I’ve been googling around but the only thing I found that was similar was from 2021 around PMIs, which is not relevant here. Open meeting using ZAK started today to ask for credentials - API and Webhooks - Zoom Developer Forum

Quite a number of views. No response. Should I be making a new support ticket?

We just had ANOTHER instance of a meeting not allowing the host to start. We tried re-fetching a brand-new start_url by calling the GetMeeting endpoint. The new start_url had the same issue. We needed to generate an entirely new meeting to get the participants into the meeting successfully.

This is becoming extremely disruptive to our daily business. Is this on anyone’s radar?

@BetterMynd ,

Sorry for not responding to this topic sooner. I am happy to help look into this matter. To begin, can you share the support ticket number so I can review the ticket? Once received, I will review and follow up here with the next steps.

Hey @donte.zoom ,

Ticket #16974601

Thanks for the response! We can provide the latest start_url as well, if necessary.

Thank you so much!

Any news on this? We still consider this an open matter. Thanks!

@donte.zoom Any news on this?

@BetterMynd,

Thanks for the follow-up here, based on the details shared, the behavior you are seeing does not happen constantly. For the meetings asking for password, when retrieving the start_url, are those meetings configured differently (i.e. password required)? Are you seeing any difference in the URL? For example, are there extra URL query parameters?

Also, is the user joining/starting the meeting via the Meeting SDK or Zoom web client?

Start meetings

Start meetings and webinars with a Zoom user’s ZAK token

For the meetings asking for password, when retrieving the start_url, are those meetings configured differently (i.e. password required)?

All meetings are generated the same way by our application. Only topic, start_time, and password will differ between creation requests. Passwords are not and never have been required, as the start_url contains the zak token for one click joining.

{
   "topic": "{generated topic}",
   "type": 2,
   "start_time": "{generated start time}",
   "duration": 110,
   "password": "{generated random password}",
   "settings": {
      "join_before_host": true,
      "close_registration": true,
      "approval_type": 0,
      "registration_type": 2,
      "registrants_email_notification": false
   }
}

Are you seeing any difference in the URL? For example, are there extra URL query parameters?

The URL does not appear to have any additional query parameters. The service ticket we provided the number for has the exact start_url used for the meeting. Decoding the zak token’s payload even shows they had not expired at the time of the meeting.

Additionally, new start_urls fetched from a GetMeeting call will have the same issue. The user will be prompted to log in. These re-fetched start_urls also have a zak token that indicates it has not expired.

Going on over a month since this thread was started. Plus a few weeks since our original ticket. Is there any movement on this? All details are in the original support ticket, #16974601, including the original start_url that has the issue.

Thank you

Found this while googling for something else, but IIRC the start_url returned here is only good for so many hours. In our application we query the GetAMeeting endpoint to get a new start URL when displaying a previously created meeting.

Not sure if you ever got this figured out and it’s a super late response, but hopefully this helps.

Appreciate the post. Unfortunately, we never got an answer. The zak tokens were all well before their expiration dates, and the tokens with the issue had no differences to similar tokens generated around the same time (also living for weeks before being used).

I believe the GetMeeting endpoint would also return an “invalid” token. We ended up needing to manually recreate meetings and shuffle ids around internally to get our people where they needed to be.

Given it hasn’t happened in a while, I assume it’s something to do with a signing token. Maybe Zoom had one in their pool that expired within a few days of signing some tokens. Would explain why only some zak tokens were affected, and new meetings don’t have the issue.

Anyways, thanks for the post, and good luck out there!