Prevent Participants from Joining After Meeting Ends or Resolve Report Consolidation Issue

API and Webhooks
1

We are encountering an issue with Zoom meetings where participants can rejoin using the same meeting link, even after I’ve explicitly ended the meeting. This creates multiple sessions under a single Meeting ID, leading to challenges with reporting and data accuracy.

When I retrieve participant data via the Zoom API, it only provides details for the most recent session. This makes it difficult to get a comprehensive list of all participants across all sessions under the same Meeting ID.

Current API Requests in Use:
To retrieve participant details, I’m using the following API requests:

curl --request GET \
  --url https://api.zoom.us/v2/report/webinars/ABCDE12345/participants \
  --header 'Authorization: Bearer YOUR_SECRET_TOKEN'

curl --request GET \
  --url https://api.zoom.us/v2/report/meetings/__MEETINGID__/participants \
  --header 'Authorization: Bearer YOUR_SECRET_TOKEN'

These calls work for individual sessions but do not consolidate participant data across multiple sessions.

Issues:

  1. Multiple Sessions Creation: Participants can rejoin a meeting after it’s ended, creating multiple sessions under the same Meeting ID.
  2. Reporting Accuracy: When I retrieve the participant report, it only reflects the participants of the most recent session, ignoring data from earlier sessions under the same Meeting ID.

Requirements:
To resolve these issues, I’m looking for:

  1. A way to prevent participants from rejoining a meeting after it has ended. If participants couldn’t join after the meeting ends, it would ensure there’s only one session per Meeting ID and simplify reporting.
  2. Alternatively, an API endpoint or method to retrieve a consolidated participant report that includes all sessions under the same Meeting ID.

Questions:

  1. Is there a setting or configuration to block participants from rejoining a meeting after it’s explicitly ended?
  2. If this behavior cannot be enforced, is there an API-based solution or workaround to aggregate participant data across multiple sessions under the same Meeting ID?

Your assistance with addressing these issues would be greatly appreciated!

2

Thank you for posting on the Zoom Developer Forum, @software4 ! I’m happy to help you get started. First, I’d like to understand how you are configuring your meetings, as this configuration determines what participants can do when joining. To help you achieve your desired results, could you please share a sample request that you’re using when creating meetings?

3

@donte.zoom please find the configuration of our meeting and webinar creation below.

Meeting
URL: https://api.zoom.us/v2/users/*zoomUserId*/meetings
Method: POST
Header: Authorization: Bearer access_token
Body:

{
      agenda: meetingTitle,
      schedule_for: zoomEmail || 'software@tagmango.com',
      join_before_host: false,
      settings: {
        allow_multiple_devices: true,
        waiting_room:  true or false,
        alternative_hosts_email_notification: true,
        approval_type: 0 or 2,
        authentication_domains: 'tagmango.com',
        mute_upon_entry: true,
        participant_video: false,
        private_meeting: true,
        registration_type: 1,
        use_pmi: false,
        auto_recording: 'cloud' or 'none',
      },
      topic: meetingTitle,
      type: 2,
}

Webinar
URL: https://api.zoom.us/v2/users/*zoomUserId*/webinars
Method: POST
Header: Authorization: Bearer access_token
Body:

{
      agenda: webinarTitle,
      schedule_for: zoomEmail || 'software@tagmango.com',
      settings: {
        approval_type: 0 or 2,
        authentication_domains: 'tagmango.com',
        mute_upon_entry: true,
        participant_video: false,
        private_meeting: true,
        registration_type: 1,
        use_pmi: false,
        auto_recording: 'cloud' or 'none',
      },
      start_time: startTime.toISOString(),
      timezone: 'UTC',
      topic: webinarTitle,
      type: 5
}
4

@software4 , Thank you for providing those details. I notice you have join_before_host set to false (and it looks like is in not set in the setting object). Could you confirm whether participants are able to enter the meeting? In my testing, when join_before_host is set to false, participants cannot join the meeting. This behavior also applies when the waiting room is enabled. Here is a Zoom clip demonstrating this experience: