Best practice to carry a stable participant identifier from join links to speakers in cloud recordings/transcripts (2-person meeting)

API and Webhooks
1

Title

Best practice to carry a stable participant identifier from join links to speakers in cloud recordings/transcripts (2-person meeting)

Category
API & Webhooks

Body
Hi Zoom team,

Use case
We run 2-person interviews (“A” and “B”). After the meeting, we need a reliable way to attribute everything said in the cloud recording/transcript to the correct person—without relying on display names.

Requirements

Each participant joins via a link that uniquely identifies them (e.g., “Simon” vs “David”).

After the meeting, we can fetch artifacts (audio/transcript) and map text/audio segments to the correct person.

Join-link → webhook → recording:
Is there any officially supported way to pass a custom external user ID (or tag) through the join link and have it echoed back in meeting webhooks and/or recording metadata? If not, is registrant_id (from Registration) the recommended stable key that persists across events?

Per-participant audio mapping:
For the per-participant M4A files delivered via recording.completed / recordings API, is there a documented mapping from each audio file to a stable participant key such as registrant_id or participant UUID? Today filenames look name-based—not ideal for automation. What’s the best-practice here?

Transcripts/subtitles attribution:

Is the TIMELINE artifact (if available) considered the canonical way to align “who spoke when” and then map that to a stable participant identity?

Are there plans to expose a stable participant identifier (e.g., registrant_id) directly in transcript metadata or a transcript API so we can attribute lines to A/B without guessing?

If none of the above is supported:
What is Zoom’s recommended pattern to achieve:
(a) unique join links that carry identity; and
(b) post-meeting artifacts (audio/transcript) where we can deterministically attribute text/audio to the correct participant?

2

Hi @jason17!

The best practice is to use Zoom’s Registration system, as you can’t just pass your own custom IDs in a join link and have them show up in the recording artifacts.

First, you’ll need to register both of your participants (A and B) for the meeting using the API. When you do, Zoom gives you a stable registrant_id for each of them. Make sure to store this ID and connect it to your internal user records.

The next critical step is to listen for the participant.joined webhook. When a participant joins using their unique registration link, this webhook payload will contain both their registrant_id (which you’ve already stored) and their new in-meeting participant UUID. This is where you create the connection. You must map the registrant_id to this new UUID in your database, as this UUID is the key for all the post-meeting files.

Once the meeting is over, you can confidently identify everyone. For the separate audio files, just look at the participant_audio_files array in the recording.completed webhook or API response. It provides a direct map, linking each participant’s UUID to their specific M4A download URL. There’s no need to guess with timestamps.

It works the same way for transcripts. When you download the VTT transcript file, you’ll see that every single line of dialogue has a <v Uuid="..."> tag, telling you exactly which UUID spoke that line.

So, that’s the pattern: register participants to get a registrant_id, use the participant.joined webhook to map it to a UUID, and then use that UUID to find the correct audio files and attribute speech in the transcript.