Skip to main content
POST
Message a Reason

Authorizations

Authorization
string
header
required

Your Reason API key from Settings › API keys. New keys use reason_; legacy ara_ keys remain accepted. Keys are capability-scoped: run, mcp:read, mcp:write, secrets:read, secrets:write, sessions:read, sessions:debug, knowledge:read, memory:read, memory:write, skills:read, skills:write, repos:read, repos:write, reviews:read, reviews:write, deployment:read, analytics:read, org:read, org:write, attachments:read, attachments:write, guardrails:read, guardrails:write, network:read, network:write, automations:read, automations:write, agent_auth:read. network:read and network:write are opt-in, excluded from default keys. network:read reads the saved workspace network policy; network:write replaces custom allowed hosts and requires a current organization owner/admin. Legacy project PATCH requests containing network_allowed_hosts also require network:write plus their existing run scope and project management permission; saved project hosts do not affect current session egress. Only owners/admins can mint or manage keys with network:write; keys cannot grant themselves more authority. See /docs/network-policies for replacement semantics and runtime applicability. mcp:write manages MCP server configuration only; it does not authorize remote MCP-tool execution. sessions:read reads sessions, including the assistant, reasoning and tool activity in their events. sessions:debug is privileged: only for organization owners/admins, it expands session events to the full diagnostic projection (diagnostic event kinds, status text and raw event metadata).

Headers

X-Reason-Agent
string

Optional self-reported caller agent name. If absent, the server uses the User-Agent for external callers.

Maximum string length: 80

Path Parameters

orgId
string
required

Organization id or slug. Resolve it with GET /v3/self.

reasonId
string<uuid>
required

The Reason id, returned as id by listReasons and createReason.

Body

application/json
message
string
required

The follow-up instruction for the agent. It reaches the running turn or starts the next one; the response's delivery says which.

attachments
object[]

Up to 10 attachments; maximum 64 MiB per file and 80 MiB total decoded bytes. The endpoint's request-body limit also applies to the encoded payload.

client_message_id
string

Caller-generated idempotency key. Reusing it for the same Session returns the original accepted turn.

Required string length: 1 - 160
model
string

Optional model id from GET /agent-auth/models to retry this session on. A model override always starts a new continuation run, because a run's model is fixed at its first execution. Omit or use auto to keep the session's current model.

reasoning_effort
enum<string>

How much reasoning the model should use for the follow-up turn. Higher effort trades time and token usage for more deliberation; supported levels depend on the selected model. Omit to retain the Session's effort setting.

Available options:
minimal,
low,
medium,
high,
xhigh,
max
allow_model_rollover
boolean

Same as the create field, for this and later turns: the follow-up goes on with the provider's other accounts, then Reason, when the Session's subscription or key runs out. A Session that already rolls over keeps doing so.

delivery
enum<string>

While a turn runs: steer (the default) hands the message to the running turn; queue holds it until the turn ends and then runs it as the next one. A queued message can be sent at once or withdrawn with its message_id (POST .../messages/{messageId}/steer, DELETE .../messages/{messageId}/queued). Not combinable with target.

Available options:
steer,
queue
target
object

Moves the Session: this message's turn, and every later one, runs on this target instead of the one the Session was on. Same shape and admission as the create target (cloud, a Device and root, or a named Machine). Only the conversation moves; files on the previous machine do not, unless they were pushed to the Session branch. A move starts a new continuation run, so the Session must have finished its current turn. Any target other than cloud needs the devices:use scope.

Response

Message accepted and delivered or queued.

ok
boolean
required

True: the message was accepted.

reason_id
string<uuid>
required

The Reason the message went to.

session_id
string
required

The Reason's conversation Session the message was added to. getSession and listSessionEvents read it; listReasonMessages reads the replies.

conversation_created
boolean
required

True when this message opened the Reason's conversation for the first time.

delivery
string

How the message was delivered: steered_live (into the running turn), queued_for_next_turn or held_in_queue (waits for the turn to end), started_continuation_run or reattached_warm_session (started a new turn), applied_to_queued_run, saved_for_follow_up (saved; see held_reason), queue_cancelled or continuation_blocked.

continuation_session_id
string | null

The stable logical Session id after an accepted follow-up. Continue polling this id; Reason may run the turn in a hidden execution Attempt.

message_id
string

Set for a message sent with delivery queue: the id to send it at once or withdraw it while it waits.

client_message_id
string

The message's idempotency key: the client_message_id sent, or the one the server gave it. Resending the message with it returns this accepted turn instead of adding another.

held_reason
string

Present when delivery is saved_for_follow_up and the message is waiting instead of starting. session_machine_transition_pending: the Session's machine is changing; the message is delivered when the change settles, so do not send it again. If the change has not settled after 10 minutes the message is marked not delivered instead.