Skip to main content
POST
Append user/system events to a session

Authorizations

Authorization
string
header
required

A Recursion API key, created in the console under API keys.

Path Parameters

session_id
string<uuid>
required

Session id (UUID) as returned by startSession or listSessions.

Body

application/json

Request body of POST /v1/sessions/{session_id}/events. It has two mutually exclusive forms and events wins: send message for the common case of one plain-text user turn, or send events as ordered typed turns with provider-shaped content. An empty events array always yields exactly one user turn built from message, even when message is empty. The handoff_resolved control form rejects all message and referenced-session fields. The response acknowledges durable acceptance of the turn, not the agent's reply.

actor
string

Who the turn is attributed to. Defaults to human:api when omitted.

events
object[] | null

Typed events to append instead of message. When present, message and the top-level actor are ignored.

message
string

Plain-text message to append as a single user turn. Used only when events is empty.

referenced_session_ids
string[]

Prior sessions this session may read from this turn on, by session id, added to any it already has. Each id is authorized under your own scope and grants read access to the whole tree containing it; one you cannot read refuses the whole request with 404 and delivers no message. The grant is recorded before the message, so the turn it starts is the first one that can use it.

Maximum array length: 10

Response

Shared response body of POST /v1/sessions/{session_id}/events and POST /v1/sessions/{session_id}/interrupt-and-send. It acknowledges durable acceptance of the turn, never the agent's reply: read the reply by listing events or streaming. Compare events_accepted against what was sent to detect silently dropped entries, and read delivery_state to learn whether an agent is actually going to act on them. events_accepted counts canonical events rather than requests, so interrupt-and-send reports 2 for its single instruction: the stop and the message that follows it.

Shared response body of POST /v1/sessions/{session_id}/events and POST /v1/sessions/{session_id}/interrupt-and-send. It acknowledges durable acceptance of the turn, never the agent's reply: read the reply by listing events or streaming. Compare events_accepted against what was sent to detect silently dropped entries, and read delivery_state to learn whether an agent is actually going to act on them. events_accepted counts canonical events rather than requests, so interrupt-and-send reports 2 for its single instruction: the stop and the message that follows it.

delivery_state
enum<string>
required

How the accepted events reached a reader. queued: the agent was mid-turn, so the input is waiting outside the transcript and the next turn boundary will read it; interrupt to bring that forward. signaled: the running session was woken and will act on them. resumed: the session had already finished, so it resumed to act on them. stored: appended to the timeline with nothing running to act on them yet.

Available options:
stored,
signaled,
resumed,
queued
events_accepted
integer
required

How many canonical events were written or queued. This counts the inputs actually derived from the body, not its length: a plain message body yields 1, and a typed event with an unrecognised type or no content is dropped, so this can be lower than the events array sent.

ok
boolean
required

Always true. Every event in the request was durably accepted; any partial or total failure is an HTTP error instead, so this field never reports false.