Skip to main content
While the meeting runs, the bot captures audio and Telnyx STT transcribes it in real time. You have two ways to read segments as they are produced: a WebSocket stream (alpha) or incremental long polling.

Read the Transcript Incrementally

GET /v2/meeting_sessions/{id}/transcript returns segments in ascending seq order, at most limit per page (default 100, maximum 1,000). Use after to page forward and wait_seconds to hold the request open (up to 25 seconds) so new segments arrive as soon as they are produced:
wait_seconds turns the call into a long poll: if no new segments exist yet, the request waits and returns as soon as a new segment lands or the timeout elapses (an empty data array with "next_after": null). Pass meta.next_after as the next request’s after cursor; on an empty page keep the cursor you already had rather than replacing it with null.

Connect to the WebSocket Stream

The stream endpoint replays stored events and transcript segments, then follows the meeting live. Open a connection with your API key on the upgrade:
Send your API key in the Authorization header using the Bearer scheme on the upgrade request. Header auth is the only supported mechanism — query-string credentials such as an access_token parameter are rejected with 401. Browser-native WebSocket clients cannot set the Authorization header during the handshake, so connect from a backend and relay to the browser if needed. A successful upgrade returns 101. Before upgrade, the server can return 401 for missing or invalid credentials or a nonexistent, foreign, or already-terminal session; 403 for a forbidden credential; 429 with Retry-After when authentication is overloaded; or 503 while authentication is unavailable.
This is a WebSocket upgrade endpoint, not an ordinary HTTP GET route. A plain curl request — or a request with only partial upgrade headers — can reach the Meeting service and return an HTML Cannot GET response even when the WebSocket route is available. Use a WebSocket client that performs the complete handshake; verify a successful connection by the 101 Switching Protocols response and incoming frames.
For example, connect from a backend terminal with wscat. The Meeting Session must belong to the API-key account and must not be in a terminal state:
A successful connection prints Connected (press CTRL+C to quit) and begins receiving JSON frames. To test bidirectional commands while the session status is active, enter a command such as:
The meeting receives the chat message and the socket receives the corresponding chat.sent event. Press Ctrl+C to disconnect. Set after_seq and after_transcript_seq to the last sequence numbers you have seen. The server replays stored records after those cursors, then switches to live delivery. Replay is bounded: each connection replays at most 1,000 event rows and 1,000 transcript rows, and a {"kind": "truncated", "store": "events" | "transcript"} frame signals that more rows remain — reconnect with that store’s cursor set to the last sequence received, or backfill through the REST endpoints. Catch-up and live delivery can overlap, so tolerate duplicates; catch-up event frames carry a durable top-level seq while live event frames may not, and a sequence-less live frame must not advance your durable cursor. Transcript segments arrive in two shapes, and a client has to handle both. Segments replayed from the transcript store during catch-up arrive as standalone transcript frames:
Segments produced live during the meeting arrive instead as event frames, with the segment nested under payload:
A client that branches only on kind == "transcript" receives nothing while a meeting is live — silently, with no error — because every segment produced after connection is an event frame. Other frame kinds (event, error, truncated) and the complete frame protocol — payload schemas, commands, and close codes — are specified in the Meeting Session agent stream reference. Segment fields (seq, text, speaker_label, confidence, relative_ts, occurred_at) are documented on List meeting session transcript.

Sending Commands over the Stream

You can make the bot act from the same socket. Send a JSON frame:
The stream allows at most 8 commands in flight or queued, and there is no per-command acknowledgement. Inbound frames larger than 32 KiB close the connection with code 1009, and if the server’s outbound buffer backs up it closes with code 1013 and reason backpressure — reconnect with your last durable cursors. For durable, acknowledged control prefer the REST actions.

Availability

The WebSocket stream is currently an alpha feature and is not covered by a stability or availability commitment. The long-polling transcript endpoint above works on the standard API and is the supported way to read the transcript today.
  • Session Events — the stored event history behind the stream
  • Join a Meeting — create a meeting session and send the bot
  • Meeting Presence — control how the bot appears and acts in the meeting, from its roster name to speaking and chat
  • Collect Results — read the finalized transcript and summary