Zoom meeting ID documentation inconsistent

[SpeakingPartner_Teac (SpeakingPartner)]

Description
We recently ran into problems when consuming API endpoints and webhook payloads because the meeting IDs were changed from int to long. This was listed in the “API Updates 04/12/2020” changelog, which was posted the day after the changes were deployed.

Upon inspection of the docs, we found that the type listed for the meeting ID is inconsistent. At the moment, and based on the changelog entry, we have implemented an int64 / long meeting ID. But some of the docs list the meeting ID as string. Can you confirm which is correct? Here’s what we found, based on API routes and webhooks that we use. Thanks.

Create Meeting
https://marketplace.zoom.us/docs/api-reference/zoom-api/meetings/meetingcreate
POST /users/{userId}/meetings
Request: n/a
Response: int64
Issue: none

Get a Meeting
https://marketplace.zoom.us/docs/api-reference/zoom-api/meetings/meeting
GET /meetings/{meetingId}
Request: int64
Response: int64
Issue: none, unless the meeting ID as a querystring parameter should be listed as string

List Meeting Participants
https://marketplace.zoom.us/docs/api-reference/zoom-api/dashboards/dashboardmeetingparticipants
GET /metrics/meetings/{meetingId}/participants
Request: string
Response: n/a
Issue: request meeting ID listed as string, unless this is intentional since it is used in the querystring

List All Recordings
https://marketplace.zoom.us/docs/api-reference/zoom-api/cloud-recording/recordingslist
GET /users/{userId}/recordings
Request: n/a
Response: string
Issue: Meeting ID is listed as a string

Get Meeting Recordings
https://marketplace.zoom.us/docs/api-reference/zoom-api/cloud-recording/recordingget
GET /meetings/{meetingId}/recordings
Request: string
Response: string
Issue: request meeting ID is listed as string, unless that’s intentional; response meeting ID is listed as string

Delete Meeting Recordings
https://marketplace.zoom.us/docs/api-reference/zoom-api/cloud-recording/recordingdelete
DELETE /meetings/{meetingId}/recordings
Request: string
Response: n/a
Issue: request meeting ID is listed as string, unless that’s intentional

Recording Completed Webhook
Payload: string
Issue: meeting ID is listed as string

Meeting Started
Payload: string
Issue: meeting ID is listed as string

Participant Joined
Payload: string
Issue: meeting ID is listed as string

Participant Left
Payload: string
Issue: meeting ID is listed as string

Meeting Ended
Payload: int64
Issue: none

[tommy (Tommy Gaessler)]

Hey @SpeakingPartner_Teac,

Thanks for pointing this out.

@shrijana.g @michael.zoom can you take a look at the docs inconsistencies?

Thanks,
Tommy

[shrijana.g (Shrijana)]

@tommy @SpeakingPartner_Teac This is by design. It is correct, the ones that are listed as int64 are of the long data type and the ones listed as string are “string”. We only changed int32 to int64, meeting IDs for webhooks/APIs which were previously returned as string, are still of string type.

Thanks,
Shrijana

[SpeakingPartner_Teac (SpeakingPartner)]

Hi @tommy and @shrijana.g,

Thanks for the reply. From an implementation perspective this inconsistency feels problematic. Does the webhook meeting started meeting_id (string) reference an entity that is different than what is referenced by the webhook meeting ended (int64) meeting_id? If not, shouldn’t these both be the same data type since they reference the same thing? Or should we expect the meeting started meeting_id to contain non-numeric characters at some point, and therefore diverge from int64 meeting_ids being used in other places? Any additional info you can provide is greatly appreciated, as we’d like to adhere to the correct implementation and avoid any surprises from our misunderstanding. Thanks!

[v.hristov (Ventsislav Hristov)]

Hi,

Just a pointer from my side on this topic, based on our experience mainly with webinars, but I think it applies also to meetings. The webinar/meeting ID you get when you schedule the meeting/webinar is the int/long numeric one. However, the meeting/webinar host can start and end the same meeting/webinar multiple times. Each such occurrence/instance of the meeting/webinar gets its own separate instance UUID. Some of the API calls provide information for a particular meeting/webinar instance, so they expect that you provide the string meeting instance UUID, not the int/long meeting ID. These API endpoints also allow you to provide the numeric ID in the place of the same string parameter, in which case they give you back the information for the latest instance of the meeting.
I think it is specified in the documentation as well, for example, look at the description of the “meetingId” path parameter in https://marketplace.zoom.us/docs/api-reference/zoom-api/dashboards/dashboardmeetingparticipants

Hope this helps,
Ventsislav

[SpeakingPartner_Teac (SpeakingPartner)]

Hi @v.hristov,

Yes, you are correct that there is also a meeting_uuid that corresponds to each unique launch or instance of a specific meeting. The uuid is definitely alpha-numeric and is listed as a string in documentation. However, I am referring to the meeting_id, which at this point is always numeric, and is usually referenced in the docs as being of type long or int64, or in some cases a “number”. But there are also other places, as listed, where the meeting_id is listed as a string.

For example, here are some screenshots of the docs referenced above:

GET /users/{userId}/recordings
**Notice that uuid is correctly listed as a string, then below the id is also listed as a string.

Meeting Started Webhook
**Notice that uuid is correctly listed as a string, then below the id is also labeled as a string, even though the description references the “long” format.

Meeting Ended Webhook
**Here, notice that id is correctly listed as an integer, and uuid is correctly listed as string.

My reason for the post was to:

1. Confirm that the meeting id (not uuid) should always be numeric/long/int64
2. Assuming that is the case, just provide a heads up to the Zoom dev or docs team

This really just seems like a documentation issue to me. @tommy, as a developer advocate, maybe you can gently point this out again? Thanks.

[shrijana.g (Shrijana)]

Hi @SpeakingPartner_Teac

Thanks for your feedback! We have made updates to the docs where needed, however, the Meeting ID is not in long format in all cases. For some APIs and Webhooks, it is still string (as documented). It was a design flaw and our team will work on making it consistent in the future. However, it might not happen anytime soon as that would break the existing integrations. We truly appreciate your feedback and understand that the inconsistency makes it difficult for you and will work on a resolution for it. Please let us know if you find any other issues.

Thanks,
Shrijana

[SpeakingPartner_Teac (SpeakingPartner)]

@shrijana.g,

Thank you very much for acknowledging and confirming the issue! The additional information you provided helps us to better understand and handle the situation. And, for us developers out here, it is totally relatable! I know there are many much more important features to work on, so we’ll manage with this current implementation for the time being.

Cheers!

[tommy (Tommy Gaessler)]

Thanks Shrijana!

@SpeakingPartner_Teac, let us know if we can help answer any other questions!

-Tommy