Meeting Participants Report API -- URL Encoding Change?


When making a call to the report meeting participants API, and when the meeting ID contains a “+” character, the API now expects that character to only be URL encoded once. While this does seem sane, previously (before 7/23 of this past month) these values needed to be double URL encoded (there are several topics on this in the forum).

I can find no API release notes regarding this change. Was this change intentional, and customers need to update their code? Or was it not intentional, and we should expect it to be fixed / rolled back?


Instead of receiving the participants, I get a “Error: No participants found”, and the API now interprets the double encoded “+” as a space character. Previously this value needed to be double URL encoded.

Which App Type (OAuth / Chatbot / JWT / Webhook)?


Which Endpoint/s?

The report meeting participants API

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Make a request to the above endpoint with a meeting ID that has a “+” character in it. Only URL encode the character once. See that it returns results. URL encode it twice, then verify it does not return results.

Additional context

I use this endpoint:

The API endpoint specifically is this one:

Due to new user status I could only put one link in my original post…

Hi @chad.sikorra,

Can you share the UUID that you’re using? I’ll be happy to take a closer look.


An example meeting ID would be:


Thanks for sharing @chad.sikorra — I’m not seeing any recent instances of this meeting having been held. Can you confirm this was held recently?

Perhaps I’m referencing the wrong UUID you’re looking for? That’s an ID that would be used here:{meetingId}/participants

So my API call that returns data (since not double encoded) is:

Thanks for clarifying @chad.sikorra — I’ve engaged our Engineering team to see if there has been a recent change to this encoding requirement, and I’ll follow up shortly (ZOOM-298019).

Hi @will.zoom , any updates on this from your side?

Hi @chad.sikorra,

Thanks for following up on this—our team has identified a bug here that appears to be specific to gov accounts. The URL encoding shouldn’t have changed. Our team is working on reverting this and I hope to have an update to share shortly (ZOOM-298019).


This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

Hey @chad.sikorra,

I’m reaching out to let you know that we haven’t forgotten about this. I’ve followed up with our team for a status update and will let you know what we hear.



Hi @MaxM and @will.zoom. The issue has been resolved and the API is now responded properly for us when an ID contains a “+” character. We had an official ticket open with Zoom support as well as this posting here, apparently the issue was confined to the ZoomGov API. But this can be marked resolved.

Thanks again for the help.

Thank for confirming @chad.sikorra!