HTTP GET - List Webinar QA fails for UUID path parameter starting with ‘qa’ because it matches the end of the API path segment?
Description
I am unable to use the List Webinar QA endpoint for a particular webinar UUID. I have confirmed this is a valid webinar UUID and it works in any other API calls that expect a webinar UUID as the path parameter (e.g. I can successfully use it with List Webinar Participants). The first 2 characters of this particular webinar UUID are ‘qa’ (qaTE7VAiSkanHObnTmOszA==) and I am speculating that it is causing the List Webinar QA endpoint to incorrectly parse the path parameter because those first two characters match the end of the path segment for this endpoint (see additional context below for my speculation on why I believe this observation is important).
Error
Invalid path parameter: webinarID
Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT
Which Endpoint/s?
https://marketplace.zoom.us/docs/api-reference/zoom-api/webinars/listpastwebinarqa
How To Reproduce (If applicable)
This will be difficult to reproduce without an organically valid webinar UUID that begins with the characters ‘qa’, but it would work as follows:
- HTTP GET https://api.zoom.us/v2/past_webinars/qaTE7VAiSkanHObnTmOszA==/qa
- See response code HTTP 400 (Bad Request) and JSON response code/message indicating that the webinarID path parameter is not valid.
Screenshots
Example of failing HTTP GET to List Webinar QA:
Example with same UUID success at another endpoint:
I can only put one embedded media item in a post, so I had to remove this screenshot. Needless to say, HTTP GET
/v2/metrics/webinars/qaTE7VAiSkanHObnTmOszA==/participants?type=pastreturns an HTTP 200 OK with participant records in the reponse as expected.
Additional Context
I have noticed that your API is very robust in being able to detect UUID values in the path (even when ‘/’ characters appear in the UUID). This made me wonder if it was doing some sort of regex tokenization/parsing of the path segments and is figuring out the UUID based on position of the known path segments (e.g. in this case ‘/past_webinars/’ and ‘/qa’). If that is the case, I could very much understand how that logic might not account for the edge case in which the UUID begins with the characters in the trailing known path segment (‘/qa’). In short, I am speculating that an HTTP GET with path segments of:
.../v2/past_webinars/qaTE7VAiSkanHObnTmOszA==/qa
is effectively being interpreted as:
.../v2/past_webinars/qa
in which the {webinarID} path parameter gets evaluated as empty (which would explain the HTTP 400 response and the “invalid path parameter: webinarID” message).