> ## Documentation Index
> Fetch the complete documentation index at: https://developers.telnyx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Session Events

> Read the ordered event history for a meeting session, and choose between polling, webhooks, and the stream.

Everything a session does -- joining, admission, speech starting and stopping, chat, recordings, artifacts -- is recorded as an ordered event with a monotonic `seq`. The same events reach you three ways, and they do not carry the same coverage:

|                                                   | Delivery            | Carries                                                  |
| ------------------------------------------------- | ------------------- | -------------------------------------------------------- |
| `GET /events`                                     | You poll            | Every event type below, including after the meeting ends |
| [Webhooks](/docs/meeting/webhooks)                | Telnyx pushes       | Five summary events -- see the table on that page        |
| [WebSocket stream](/docs/meeting/live-transcript) | Telnyx pushes, live | Every event type, live, plus transcript catch-up         |

The stored history is the authoritative record. A webhook that never arrived, a socket that dropped mid-meeting, or a process that restarted are all recovered the same way: read from the last `seq` you durably stored.

## Read the Event History

`GET /v2/meeting_sessions/{id}/events` returns events in `seq` order.

```bash theme={null}
curl "https://api.telnyx.com/v2/meeting_sessions/mtgsess_9b2f.../events?limit=100" \
  -H "Authorization: Bearer $TELNYX_API_KEY"
```

```json theme={null}
{
  "data": [
    {
      "seq": 12,
      "type": "session.status_changed",
      "payload": { "status": "active", "previous_status": "waiting_for_admission" },
      "occurred_at": "2026-06-16T09:00:05Z"
    }
  ]
}
```

Every event has the same four fields: `seq`, `type`, `payload`, and `occurred_at`. The shape of `payload` is determined by `type`.

### Paging and Resuming

Pass `after` with the highest `seq` you have already processed, and `limit` for the page size. Because `seq` is monotonic within a session, the same parameter serves both jobs -- paging through a completed session and resuming after an interruption are the same request.

```bash theme={null}
curl "https://api.telnyx.com/v2/meeting_sessions/mtgsess_9b2f.../events?after=12&limit=100" \
  -H "Authorization: Bearer $TELNYX_API_KEY"
```

Store `seq` only after the event is processed. Storing it on receipt means an event lost to a crash is never re-read, and there is no way to detect the gap afterwards.

## Event Types

Not every type is delivered by every mechanism -- webhooks carry the five summary events listed on the [Webhooks](/docs/meeting/webhooks) page, while `GET /events` and the stream carry all of them.

| Event                          | Meaning                                                                |
| ------------------------------ | ---------------------------------------------------------------------- |
| `session.created`              | The session record exists; the bot has not necessarily joined.         |
| `session.status_changed`       | Lifecycle moved -- carries `status` and `previous_status`.             |
| `participant.join`             | Someone joined the meeting.                                            |
| `participant.leave`            | Someone left.                                                          |
| `participant.speech_on`        | A participant started speaking.                                        |
| `participant.speech_off`       | A participant stopped speaking.                                        |
| `transcript.segment`           | One transcribed segment. Never delivered by webhook.                   |
| `transcript.completed`         | The transcript is finalized -- carries `segment_count` and `last_seq`. |
| `bot.speak_requested`          | A `speak` action was accepted.                                         |
| `bot.speak_stopped`            | Speech was stopped, by `stop_speaking` or by barge-in.                 |
| `bot.speak_on_enter_delivered` | The configured `speak_on_enter` line was spoken.                       |
| `chat.message`                 | A participant posted in the meeting chat.                              |
| `chat.sent`                    | The bot's own chat message was posted.                                 |
| `recording.available`          | A recording is ready -- carries `recording_types`, never URLs.         |
| `artifact.completed`           | An artifact finished -- carries `content.text`.                        |
| `artifact.failed`              | An artifact could not be generated.                                    |
| `avatar.connected`             | The avatar media channel attached.                                     |
| `avatar.degraded`              | The avatar is running in a reduced state.                              |
| `avatar.disconnected`          | The avatar media channel dropped.                                      |

Treat this list as open. The event type field is deliberately extensible, and a client that rejects an unrecognized `type` will break the first time a new one is added -- ignore what you do not recognize rather than failing. The complete machine-readable enum, with the exact payload schema bound to each type, is in the [Meeting Session agent stream reference](/api-reference/websockets/meeting-session-agent-stream).

## Choosing a Mechanism

* **Webhooks** for "tell me when it is finished" -- a summary arrives without you holding a connection, and the five events cover the end states most integrations act on.
* **The stream** for anything live: transcript as it is produced, speech starting and stopping, participants arriving.
* **`GET /events`** for everything else, and as the backstop for both. It is the only mechanism that answers "what did I miss" after the fact, so a reliable integration reconciles against it even when it is driven by pushes.

## Related

* [Webhooks](/docs/meeting/webhooks) -- push delivery, envelope, and signature verification
* [Live Transcript](/docs/meeting/live-transcript) -- the WebSocket stream and transcript polling
* [Collect Results](/docs/meeting/collect-results) -- the finalized transcript, artifacts, and recordings