But if we make that API call immediately after receiving the webhook, the API will sometimes return either 404 errors or will return an erroneous empty list when we know in fact there were participants in the meeting.
After some trial and error, we have discovered that the API call to fetch the participants will mostly work after waiting something like 15 seconds.
Are we doing something wrong? To us it seems your API has a timing issue where it sends out the meeting.ended webhook before your system is able to report the list of participants accuratelyâŚas if data is propagating among various databases/machinery in your system.
Hi @eliza.zoom, Is there any update on this? Weâre seeing the same issue. Weâd really like to be able to call the participants api when meetings end, but we get a 404 response.
The same code works fine if we call it on ârecording.completedâ so it seems itâs just a timing issue.
Our platform is a learning management platform that we integrate with Zoom. When a webinar or meeting ends, our end users expect to be able to immediately complete activities in the LMS that are contingent on having attended the webinar or meeting.
We use the meeting and webinar end meeting webhook, but about 10% of the time we get the same 404 error as @RobertYeager is experiencing. Weâve tried adding in delays but it is hard to know how long to wait.
We also experience an overlapping issue where occasionally we wonât get a 404 error but the attendee data that is returned is not complete, e.g. only 45 of 150 participant attendance data is returned.
Any advice or suggestions is greatly appreciated. We want to be able to rely on the webhook end meeting notice to be able to know when we can pull in full participation data from the event.
Thanks guys for confirming experiencing the same issue we do. We put in a 30s pause after receiving the webhook meeting.ended and before fetching âGet past meeting participantsâ. 15s probably already would have been enough after our testing, but we decided to go with 30s.
As you can see in our Splunk stats it definitely was the solution/workaround to avoid those 404 errors. Before adding the pause we had around 400 a day of those 404 errors, now since the change we only have a few a day.