Skribby
GuidesUpdated 3 weeks ago

Participant Timelines

Skribby records when participants are first seen, when they speak, and when their presence or meeting state changes. This lets you build meeting visualizations, synchronized transcripts, and participant activity timelines.

Realtime Participant Events

If you use a Real-time Transcription model or have the Real-time Audio addon enabled, you can listen for participant events via WebSockets:

  • participant-tracked: A participant was detected for the first time. Stored on the participant as first_seen_at.
  • started-speaking: A participant started speaking. Stored timeline event: started-speaking.
  • stopped-speaking: A participant stopped speaking. Stored timeline event: stopped-speaking.
  • participant-left: A participant left the meeting. Stored timeline event: left.
  • participant-rejoined: A participant rejoined the meeting. Stored timeline event: rejoined.
  • participant-muted: A participant muted their microphone. Stored timeline event: muted.
  • participant-unmuted: A participant unmuted their microphone. Stored timeline event: unmuted.
  • participant-camera-on: A participant turned their camera on. Stored timeline event: camera-on.
  • participant-camera-off: A participant turned their camera off. Stored timeline event: camera-off.
  • participant-started-screenshare: A participant started sharing their screen. Stored timeline event: started-screenshare.
  • participant-stopped-screenshare: A participant stopped sharing their screen. Stored timeline event: stopped-screenshare.
realtimeClient.on('participant-muted', (data) => { console.log(`${data.participantName} muted at ${data.timestamp}.`); });

See Realtime Transcription for the event payload.

Historical Participant Data

Once a bot reaches the finished status, you can retrieve each participant's timeline via the API. The events array contains the speaking, presence, and meeting-state events listed above.

with-speaker-events Option

By default, the GET /bot/{id} endpoint returns participant data without detailed event logs to keep the response size small. To include the participant timeline, add the existing with-speaker-events=true query parameter:

GET /api/v1/bot/{id}?with-speaker-events=true

Example Response

{ "participants": [ { "name": "John Doe", "first_seen_at": "2025-06-25T03:03:15.913000Z", "last_seen_at": 1750820624000, "presence_intervals": [ { "joined_at": 1750820595913, "left_at": 1750820611000 }, { "joined_at": 1750820624000 } ], "events": [ { "type": "started-speaking", "timestamp": 1750820602963 }, { "type": "muted", "timestamp": 1750820605120 }, { "type": "left", "timestamp": 1750820611000 }, { "type": "rejoined", "timestamp": 1750820624000 } ] } ] }

Speaker Identification

Real-time Identification

When using a real-time model, Skribby may initially label participants as Speaker 1, Speaker 2, etc. As the meeting progresses, our system correlates audio streams with the platform's participant list. Once identified, the labels will transition to actual display names (e.g., Jane Smith).

Asynchronous (Post-call) Identification

For non-realtime models, speaker identification is performed during post-processing. Skribby correlates the transcription engine's speaker segments with the meeting's participant metadata to automatically assign names to speaker IDs.

If the system is highly confident in the alignment, the speaker_name is assigned directly. In cases of lower confidence or overlapping signals, we provide a potential_speaker_names property. This includes a list of likely participants along with a confidence score, allowing your application to decide how to present the data.