Breaking Change / Bug: GET /metrics/meetings started returning lowercase identifiers instead of original casing

API Endpoint(s) and/or Zoom API Event(s):
GET /metrics/meetings
GET /rooms
PATCH /rooms/{roomId}/events

Description:
Since August 16, 2026, we have been seeing a change in the values returned by GET /metrics/meetings that has broken our production integration.

Our flow is:
We retrieve the Zoom Room ID using GET /rooms.We start a meeting using PATCH /rooms/{roomId}/events.
We query GET /metrics/meetings to find the active meeting associated with that Zoom Room.

  • Until August 15, the identifier contained in the meeting email returned by GET /metrics/meetings preserved the same uppercase/lowercase representation as the Room ID returned by GET /rooms.
  • Starting August 16, GET /rooms continues to return the original mixed-case Room ID, but GET /metrics/meetings returns the identifier entirely in lowercase.

Example from the same Zoom Room:

GET /rooms:
aPOecmV0ROCjuZb_drakJQ

GET /metrics/meetings on August 15:
rooms_aPOecmV0ROCjuZb_drakJQ@…

GET /metrics/meetings on August 16:
rooms_apoecmv0rocjuzb_drakjq@…

We have logs of the API responses covering the last two months, and we have confirmed the same change with more than one Zoom Room.

The last response where we observed the previous behavior was:
2026-08-15T23:54:20Z

The first response where we observed the lowercase behavior was:
2026-08-16T13:03:50Z

GET /rooms continues to return the original mixed-case Room IDs.

We also reviewed the Zoom Developer Changelog and could not find any published change related to this behavior.

This is currently affecting our production service. Meetings are successfully created, but our application can no longer correlate the meeting returned by GET /metrics/meetings with the corresponding Zoom Room, preventing our agents from joining the video call and serving affected customers.
We already opened Zoom Support ticket TS2414554. Technical Support redirected us to the Developer Forum because our account does not have a Developer Support Plan.

Our main question is:
Is this an unintended regression that is expected to be reverted, or is returning the Zoom Room identifier in lowercase from GET /metrics/meetings a permanent behavior change?
We need to know which behavior Zoom intends to maintain because this determines how we should proceed with our production integration.

Error?
There is no HTTP or authentication error.
PATCH /rooms/{roomId}/events returns HTTP 202.
GET /metrics/meetings returns HTTP 200 and the meeting is present in the response.
The issue is that the Zoom Room identifier represented in the meeting email is now returned in lowercase, while GET /rooms continues to return the same Room ID with its original mixed casing.

This change prevents our existing correlation from matching the Zoom Room with its meeting.

How To Reproduce
Call:
GET /rooms?page_size=300
and obtain a Zoom Room whose Room ID contains uppercase characters.

Example:
aPOecmV0ROCjuZb_drakJQ

Start a meeting for that Room using:

PATCH /rooms/{roomId}/events
Body:
{“method”:“zoomroom.meeting_join”}
Response:
HTTP 202

Query:
GET /metrics/meetings
Locate the meeting that was just created.
Compare the Room ID returned by GET /rooms with the identifier contained in the meeting email.

Current behavior:
GET /rooms:
aPOecmV0ROCjuZb_drakJQ

GET /metrics/meetings:
rooms_apoecmv0rocjuzb_drakjq@…

Before August 16, GET /metrics/meetings preserved the original casing:
rooms_aPOecmV0ROCjuZb_drakJQ@…

Authentication method:
Server-to-Server OAuth

No API error is returned. The issue is the change in casing of the returned identifier.