Inconsistent Behavior in GET /meetings/{meetingId}/registrants — Missing Pagination Token and Limited Status Filtering

I’m encountering inconsistencies between the Zoom API documentation and the actual behavior of the GET /meetings/{meetingId}/registrants endpoint.

According to the Zoom API documentation, the endpoint should support pagination using next_page_token and return registrants across all statuses. However, in practice, I’ve observed two issues:


1. Pagination Behavior

  • Documentation claim:
    The response should include a next_page_token for pagination.

  • Observed behavior:
    The next_page_token field is missing from the response.
    I need to manually iterate using the page_number parameter to retrieve additional pages.

Example response snippet:

{
  "page_count": 2,
  "page_number": 1,
  "page_size": 30,
  "total_records": 49,
  "registrants": [
    {
      "id": "REDACTED_ID_1",
      "first_name": "Registrant 1",
      "email": "user1@example.com",
      "status": "approved",
      "create_time": "2025-12-04T19:27:56Z",
      "join_url": "https://example.zoom.us/w/86069748282?tk=REDACTED"
    },
    {
      "id": "REDACTED_ID_2",
      "first_name": "Registrant 2",
      "email": "user2@example.com",
      "status": "approved",
      "create_time": "2025-12-04T19:06:09Z",
      "join_url": "https://example.zoom.us/w/86069748282?tk=REDACTED"
    }
  ]
}


2. Status Filtering Limitation

  • Observed limitation:
    The API only returns registrants for a single status type (approved, pending, or cancelled) per request.
    There’s no supported parameter or way to retrieve all registrants across all statuses in a single API call.

Example scenario:

  • A meeting has 52 total registrants

    • 49 approved

    • 2 cancelled

  • The endpoint only returns the registrants for the requested status, e.g.,

    • status=approved → 49 registrants

    • status=cancelled → 2 registrants

  • There’s no way to get all 52 in one query.


Request for Clarification

  • Is the missing next_page_token a known issue or deprecated behavior for this endpoint?

  • Is there an alternative endpoint or supported approach to fetch all registrants (approved, pending, and cancelled) for a specific meeting occurrence in a single request?

If not, could this functionality be considered for inclusion in a future API update, given its common use case for registration synchronization and analytics?


Environment:

  • App Type: Account-level Server-to-Server OAuth

  • Endpoint: GET /meetings/{meetingId}/registrants

  • Zoom API Version: v2

We’re also running into an issue with several of the Zoom Contact Center API endpoints that started on 12/4/2025. Specifically, the next_page_token is coming back as blank, which prevents us from iterating through paginated data. This is a critical for our reporting pipelines.

Before this date, pagination was working normally. Nothing has changed on our end, so we’re wondering if there may have been a recent update or change that could be affecting these endpoints.

Could this be escalated to the development team to investigate? Our organization relies heavily on this data for operational and business decisions, so any guidance or confirmation would help us plan accordingly.

API_Response_Engagements

Hey @Alden1
Thanks for reachingo ut to us.
I am not able to reproduce this on my end. I do get a next_page_token in my response.
Please try again and if you keep facing this issue, provide us with the request URL , response body and also the tracking ID found in the response headers so we can escalate this

Hey @SyntaxFoundry
Thanks for reaching out to us !
If you dont have more records to go over, the value of your next_page_token will be an empty string.
For it to populate it needs to have more data . In the example you shared note that you only have 1 record so it is expected hat you don’t next a next_page_token

Hello Elisa,

I still don’t get a next_page_token.

details:

Endpoint : GEThttps://api.zoom.us/v2/meetings/{meetingId}/registrants?page_number=1&occurrence_id=1765306800000&page_size=30

x-zm-trackingid →
v=2.0;clid=us06;rid=WEB_aa70f31defecc1e3e0c53ebae9d76dba

Response:
{
“page_count”: 2,
“page_number”: 1,
“page_size”: 30,
“total_records”: 34,
“registrants”: [
{
“id”: “REG_1”,
“first_name”: “FirstName1”,
“last_name”: “LastName1”,
“email”: “``email1@example.com``”,
“address”: “”,
“city”: “”,
“country”: “”,
“zip”: “”,
“state”: “”,
“phone”: “”,
“industry”: “”,
“org”: “”,
“job_title”: “”,
“purchasing_time_frame”: “”,
“role_in_purchase_process”: “”,
“no_of_employees”: “”,
“comments”: “”,
“custom_questions”: ,
“status”: “approved”,
“create_time”: “2025-12-09T19:06:08Z”,
“join_url”: “``https://example.com/join1”
},
{
“id”: “REG_2”,
“first_name”: “FirstName2”,
“last_name”: “LastName2”,
“email”: “``email2@example.com``”,
“custom_questions”: ,
“status”: “approved”,
“create_time”: “2025-12-09T18:32:40Z”,
“join_url”: “``https://example.com/join2”
},
{
“id”: “REG_3”,
“first_name”: “FirstName3”,
“last_name”: “LastName3”,
“email”: “``email3@example.com``”,
“address”: “”,
“city”: “”,
“country”: “”,
“zip”: “”,
“state”: “”,
“phone”: “”,
“industry”: “”,
“org”: “”,
“job_title”: “”,
“purchasing_time_frame”: “”,
“role_in_purchase_process”: “”,
“no_of_employees”: “”,
“comments”: “”,
“custom_questions”: ,
“status”: “approved”,
“create_time”: “2025-12-09T18:30:59Z”,
“join_url”: “``https://example.com/join3”
},
{
“id”: “REG_4”,
“first_name”: “FirstName4”,
“last_name”: “LastName4”,
“email”: “``email4@example.com``”,
“address”: “”,
“city”: “”,
“country”: “”,
“zip”: “”,
“state”: “”,
“phone”: “”,
“industry”: “”,
“org”: “”,
“job_title”: “”,
“purchasing_time_frame”: “”,
“role_in_purchase_process”: “”,
“no_of_employees”: “”,
“comments”: “”,
“custom_questions”: ,
“status”: “approved”,
“create_time”: “2025-12-09T15:25:02Z”,
“join_url”: “``https://example.com/join4”
}
// …so on
]
}

Hi @Alden1
Thanks for your prompt reply.
Can you please try removing the page_number field from your query parameters and try again?
This field has been deprecated and this could be causing the issue

Hey Elisa,

thanks that worked, but I’m still facing an inconsistent number with the actual registrants for a particular occurence of a meeting

API says - 34 total

but a manual report export gives me 35

Alex Bebenek alexdbebenek@gmail.com 12/9/2025 16:33 cancelled by self

The above registrant does not appear in the response