Events

Everything that happens in a session is an event: your messages, the agent’s replies and tool calls, and status changes. You send events to steer the session and read them from the history or a live stream. The events follow Anthropic’s Managed Agents API, with the differences listed at the end of this page.

Endpoints

Endpoint	What it does
`GET /v1/sessions/{session_id}/events`	Returns a session’s event history, oldest first by default.
`POST /v1/sessions/{session_id}/events`	Sends a message, a tool approval or an interrupt to a session.
`GET /v1/sessions/{session_id}/events/stream`	Streams a session’s events as server-sent events while they happen.

The event object

Field	Type	Description
`id`	`string`	The event’s ID, in the form `sevt_<seq>_<index>`.
`type`	`string`	One of the types below.
`processed_at`	`string \| null`	When the event was processed, as an RFC 3339 timestamp. It is `null` only on send receipts.

Each type adds its own fields, listed in Event types.

IDs sort in the order the events happened. Compare them by their numbers, not as strings: sevt_10_0 comes after sevt_9_0. To resume after an event, pass its ID as page on List events or as the Last-Event-ID header on the stream.

When you send an event, the response holds a send receipt: an event object with an ID of the form sevt_receipt_<uuid> and a null processed_at. The receipt’s ID is not the ID of the stored event. The stored event, with its real ID, then appears on the stream and in the history.

{
  "type": "agent.message",
  "id": "sevt_40_0",
  "processed_at": "2026-10-21T01:42:24.003Z",
  "content": [
    {
      "type": "text",
      "text": "The output is `first`."
    }
  ]
}

Event types

Types are named <source>.<action>. The session uses the 11 types below. More types might be added, so skip any type you do not recognize.

Events you send

Type	Fields	Description
`user.message`	`content`: text blocks	Starts a turn. If a turn is already running, the message joins it, and one `session.status_idle` ends the combined turn. The first `user.message` also starts the session.
`user.tool_confirmation`	`tool_use_id`, `result` (`allow` or `deny`), `deny_message`	Answers a tool call that waits for approval. `allow` approves that one call, and `deny` refuses it. The stored event carries `deny_message` only for a `deny`.
`user.interrupt`	none	Stops the current turn. The session emits `session.status_idle` with `end_turn`.

Events the session emits

Type	Fields	Description
`agent.thinking`	none	The agent reasoned before replying. The event has no content and arrives with the reply, so it isn’t a live indicator.
`agent.message`	`content`: text blocks	The agent replied.
`agent.tool_use`	`name`, `input`	The agent called a tool.
`agent.tool_result`	`tool_use_id`, `content`, `is_error`	A tool returned its result.
`session.status_running`	none	A turn started.
`session.status_idle`	`stop_reason`, `stop_details`	A turn ended. `stop_reason.type` is `end_turn`, `requires_action` (with `event_ids`, the `agent.tool_use` IDs waiting for your approval) or `retries_exhausted`. `stop_details` is always null.
`session.error`	`error.type`, `error.message`, `error.retry_status`	A step of the turn failed. `error.type` is one of the types in Session errors. With `retry_status.type: "retrying"`, the session retries and stays `running`. With `"exhausted"`, the turn failed, and a `session.status_idle` with `retries_exhausted` follows.
`session.usage`	`usage`: `input_tokens`, `output_tokens`, `cache_read_input_tokens`, `cache_creation`, `active_seconds`	Reports the session’s running totals, subagents included. The session sends it after each model call and before every `session.status_idle`. This event doesn’t include cost. To read cost, retrieve the session and read its `usage.list_cost`.

When stop_reason.type is requires_action, answer every ID in event_ids. The session doesn’t send a new session.status_idle for the IDs you haven’t answered. It runs again only after you answer the last one.

Subagents that the agent starts do not emit events of their own. The one exception is a subagent tool call waiting for approval, which shows up as agent.tool_use and a session.status_idle with requires_action.

Session errors

`error.type`	Cause
`model_rate_limited_error`	The model provider’s rate limit, or your own usage limit, was reached.
`model_overloaded_error`	The model provider is unavailable or overloaded.
`model_request_failed_error`	The model call failed for another reason, for example a timeout, a network failure, a refused request or a context window overflow.
`billing_error`	Credits, a spend limit or a budget ran out, or the agent has no billing seat in its workspace.
`unknown_error`	Any other failure, including a step the platform retries on its own without a known cause.

retry_status.type is retrying or exhausted. Any error.type can come with retrying: the platform retries on its own and the turn continues. With exhausted, the turn failed. Send a new user.message to start the next turn.

Differences from Anthropic’s API

This API follows Anthropic’s Managed Agents API, with these differences:

Event deltas, session threads and custom tools are not supported.
Sending user.tool_result, user.custom_tool_result, user.define_outcome or system.message returns 400.
Send receipts have their own ID form. See The event object.
The stream accepts a Last-Event-ID header to resume after an event. Anthropic’s API does not.
retry_status.type is never terminal, and MCP, credential and repository error types are not sent.

For every difference in one place, see Coming from Anthropic’s API.