Start_url is different

API and Webhooks Meetings
1

I created a meeting using createMeeting and cached start_url and meetingId.
Now using the same meetingId, when I call getMeeting, the start_url is different. Trying to understand why that is the case?

Thanks,
–Ram

2

Hi @ram.mummidi ,

Could you share more details such as

  • the full create a meeting request (with sensitive information removed)?
  • whether the meeting was successfully started or if it is upcoming?

Thanks!

4

Here is the meeting request json
{
“topic”: “Zoom Create Meeting Test”,
“start_time”: “2023-04-02T01:00:00Z”,
“duration”: 60,
“schedule_for”: “*****@.autodesk.com”,
“settings”: {
“host_video”: false,
“participant_video”: false,
“registrants_confirmation_email”: false,
“registrants_email_notification”: false,
“mute_upon_entry”: true,
“approval_type”: 0
}
}
The meeting was upcoming.
Thanks,
–Ram

5

Hi @ram.mummidi , please private message me the behavior showing the difference in start_url results and I will try to reproduce.

6

How do I send a private message?
Thank you,
–Ram

7

Just messaged you! You can respond there.

8

Hi @ram.mummidi ,

Thanks for sending your info over. Responding here just in case it may help someone else. Are you querying GET a Meeting immediately after POST Create a Meeting?

Does any of the following apply to you?

image
image2314×452 67.2 KB

9

Thank you @gianni.zoom. So this expected behavior. Thank you for confirming.

Have a good weekend,
–Ram

10

Hi @gianni.zoom,

Thinking more about it, I am trying to understand. What does it mean by (after expiry).
We are creating a meeting and any call of getMeeting for the same meeting, returns a different start_url from the original createMeeting start_url. And for every getMeeting call, start_url keeps changing.
Is this how the API is designed? If so, why is it so, is what I am trying to understand.

Thanks, --Ram

11

Hi @ram.mummidi , when you query GET a Meeting, you are provided with a new start url that is valid for 2 hrs from the time of API call. It is designed this way to always provide a url with the longest expiration time for immediate use.

12

Thank you @gianni.zoom.
I have one follow up question. If we are creating a meeting, let’s say 1 month down the line, the start_url that is returned is valid only for 2-hours? So but the meeting is 1 month down the line. So, I am trying to understand the documentation? Can you please explain, what that 2-hours means?

Thank you,
–Ram

13

@ram.mummidi the start URL for the host expires within 2 hrs but a new one can be generated when calling GET a Meeting. Alternatively, while the designated host is logged in, they can use the join URL to start the meeting. The join URL never expires.

14

Hi Gianni, I have a similar problem to Ram in that I run an automated system that sets up 80-100 meetings a week across Zoom and Teams. The majority of these are scheduled months in the future. Meeting URLs are sent with the Gcal invite at time of setup.

Can I confirm: you’re asking your clients to add an entire extra workflow around the API to resend invites two hours before each meeting starts?

We try to avoid last-minute changes to invitations. For us, the process is unreliable and fragile, as many of our clients are government bodies with tightly secured Outlook calendar infrastructure that doesn’t always respond correctly to updates.

I can see in the docs that there’s something called a custCreate user that might make it possible to create meeting inivites with a life of 90 days - are they only available to organisations in ISV program?

Thanks for any suggestions. It’s useful at least to know why so many URLs are breaking, even if it’s not good news for us.

15

Hi @ldnflds ,

Thanks for using Zoom!

I am not asking this, but sharing the functioning workflow to retrieve a valid start_url with respect to our current API behavior. I understand the challenges of the expiration, particularly for the use case you described. Alternatively, while the designated host is logged in, they can use the join URL to start the meeting as the join URL never expires. Could this work for you?

Yes this is just for ISV accounts.

16

Thanks Gianni,

Appreciate the response. I think I’ve now realised what I’m missing here.

Is this correct:

  • Only the host needs the start_url, and that has a two hour expiry
  • Once the meeting is started, the join_url can be used by anyone, and it does not change

This would much easier for us to deal with, as then we only need to worry about the host having the updated URL, and we have a console they use in which the URL can be updated.

Please let me know if this is the case. Thank you.

17

Hi @ldnflds ,

Yes this is correct :slight_smile:

18

Thank you, that’s very useful

1 Like
19

Hi Gianni,

Hope you are doing well. I have another question, regarding meeting API.
Is it possible to get a list of attendees, that are currently in meeting , that is in session? I see the there is an API for getting past meeting participants.
I have a use case, 10-30 minutes into a meeting, we want to get a list of participants, who joined (Not all the registered participants), and send them an email.
I see the API, to get the list of meeting participants. I am going to try that now, but based on documentation, it says, it returns a list of registered participant… doesn’t say anything about a meeting in session. Please let me, know if there is way to do it.

Thank you,
–Ram

20

Hi @ram.mummidi ,

Thanks for your patience! I was out of office. You can get current meeting attendees participants via the GET /metrics/meetings/{meetingId}/participants endpoint. Use query parameter type=live :slight_smile: