Thanks — I understand you're seeing

handle_participant_left

webhook payloads that usually lack participant metadata and want a reliable way to receive that data. Why metadata is often missing • If a participant disconnects ungracefully (network drop, client crash), the server may not have the full participant state available when emitting

participant_left

, so metadata can be absent. • Calling the

DeleteRoom

API (room immediately destroyed) can trigger

participant_left

without metadata because the room/participant state is removed before serialization. • The webhook includes metadata only when the server has the participant’s metadata available during cleanup. How to reliably capture participant metadata • Persist metadata server-side when the participant joins:

participant_joined

reliably includes metadata. Store the needed fields in your backend as the source of truth. • Track updates with `participant_attributes_changed`: listen for this event and update your backend copy whenever metadata changes. • Set important metadata proactively: call

UpdateParticipant

(or ensure metadata is set before disconnect) so it's present while the participant is active. • Treat

participant_left

as a session-end signal, not the primary source for participant data — use your backend copy to assemble full end-of-session records. If you want, tell me: • How you currently set metadata (on connect, later via UpdateParticipant, etc.) • Whether you call DeleteRoom in your flow I can then suggest specific changes to your webhook handling or event wiring to minimize missing data. Sources: Server-side | livekit/livekit_composite | DeepWiki | server-sdk-js | livekit/livekit_composite | DeepWiki | Job lifecycle | LiveKit docs