Has something changed with start_url? Users being sent to /signin

API and Webhooks
1

We have noticed that users with fresh browser session (newly opened browser), are not able to initially start a session using the given URL from the API. They are first directed to a /signing page. If they close the tab, then attempt to start the session again using the provided link it works fine.

I did a little digging and it looks like the start_url is expecting some cookies that are not initially set. But once the user has hit /signin and got some cookies, the next request works fine. We are pretty confident that this has not always been the case and are wondering if something has changed.

We are still using v1 of the API.

2

Hi Alex, 

Can you check to make sure the start_url has not expired? 

Thanks

3

Our users are also reporting this behavior, starting at the beginning of this week.  When using a newly-fetched start URL, Zoom prompts them to sign in.  If they try again, they are able to access the meeting as expected.  We have not changed our integration in the last week and so it also seems to us that something has changed on Zoom’s side.

 

4

I don’t believe it has because I am testing immediately after creating a new meeting. Also, the same exact URL starts working after I have been redirected to /signin. So basically: When I open a new browser session, from our app I click the “start session” link, the tab opens and directs me to /signin, I can close that tab, click the link again and it works as expected.

5

Hi Alex, 

I wanted to confirm if you are creating the meeting then using the start_url? Since the start_url is only for the meeting host, and the join_url is for the meeting participants.

 

Thanks

6

Yes, in our application the meeting creator only sees the start_url, participants are shown the join_url. I have even created a meeting outside of our application using the REST API directly, giving my account ID as the host_id and copying the start_url from the response. I open a new browser, paste in the start_url, and get redirected to /signin. I have tested this both with my personal account, and QA accounts we use for testing. And the report of this issue originated from our users.

7

Hi Alex - we experienced the same issue last week, but it seems to have resolved.  Are you experiencing the same thing? Did you ever get an explanation of whether a fix was deployed?  Thanks!

8

Hi Alex & Nick 

Can you try retrieve a new start_url again?  If that does not work can you please email us your start_url to developersupport@zoom.us?

Thanks

9

Nick - same for us. The issue resolved itself. I opened a support ticket, but by the time they got back to me and I went to gather some request/response data for them, I could not reproduce it. The support rep said he checked with engineering and there was no change to their system. Obviously something changed, and then got fixed. I’m kind of glad someone else experienced it since I was beginning to doubt my sanity. From my investigation it looked like they were checking for some session variables on the start_url route when they should not have been since the URL “zak” should be all that is needed to identify and verify the user’s ability to start the meeting.

 

Michael - I want to stress that there was no issue with the URL itself. The same exact URL would work fine the second time you would try and launch a meeting from a new browsing session. By all appearances this was a server configuration issue.

10

A couple of ours have reported this issue occurring again, though I’m not able to replicate.  When using a valid start_url, they are prompted to sign in. 

11

Hi Nick, 

Can you email us the start_url to developersupport@zoom.us? Our Engineers will prioritize this since this is a repeat issue. 

Thanks