Subscriptions

Subscriptions run over GET /v1/ws. You open the socket, call a *.subscribe method, and receive notifications until you unsubscribe.

Establishing a subscription

Call a subscribe method with an optional filter and replay_since. The response returns a subscription_id, then the runtime pushes notifications:

// request
{ "jsonrpc": "2.0", "id": 1, "method": "event.subscribe", "params": { "filter": { }, "replay_since": "..." } }

// notification
{ "jsonrpc": "2.0", "method": "rpc.subscription", "params": { "subscription": "<id>", "result": { } } }

Note the asymmetry: notifications carry subscription; rpc.unsubscribe takes subscription_id.

Available streams

Method	Notification payload
`run.subscribe_trace`	A composed trace row for one run (events, deliveries, sessions, turns).
`event.subscribe`	Each matching event from the event log.
`runtime.subscribe_logs`	Each matching log entry.
`health.subscribe`	A health snapshot every few seconds.

A subscribe method and its list sibling share the same filter type (for example event.subscribe and event.list). Pagination is list-only; subscriptions accept replay_since for catch-up.

Delivery semantics

Notifications are ordered per stream key (the unit the stream is keyed by) within one subscription, with no ordering guarantee across subscriptions. Delivery is eventual, not durable across disconnects, and may drop under backpressure. To recover, re-subscribe with replay_since, or reconcile with the matching list method using the same filter and a since bound.

Unsubscribing

{ "jsonrpc": "2.0", "id": 9, "method": "rpc.unsubscribe", "params": { "subscription_id": "<id>" } }

Overview

Health

Runs

Events

Entities

Mailbox

Agents

Conversations

Runtime

Protocol

Establishing a subscription

Available streams

Delivery semantics

Unsubscribing

​Establishing a subscription

​Available streams

​Delivery semantics

​Unsubscribing

Establishing a subscription

Available streams

Delivery semantics

Unsubscribing