Events

The Real Event Stream: /api/v1/sessions/events

Xenocept exposes one Server-Sent Events stream:

GET /api/v1/sessions/events

(src/api.rs:306, 1199-1228)

The payload is a JSON envelope with kind set to either created or dispatched. The Sessions list UI subscribes to this stream so the list refreshes the moment a session is submitted or successfully dispatched.

Plugins running in the frontend can also subscribe to this stream if they want to react to session lifecycle. The exact JavaScript API for “as a plugin, observe submit events” is frontend code — read the frontend plugin host for the canonical pattern.

The /api/v1/channels/events Stream

A second SSE stream:

GET /api/v1/channels/events

(src/api.rs:318)

This is the channel-server bridge for MCP — see MCP. It’s filtered server-side by channel name (src/channels.rs). It’s intended for xenocept --mcp <name> subprocesses, not for general plugin consumption.

AeorDB’s Native Events

AeorDB itself emits engine-level events (entries_created, entries_deleted, versions_created) on its internal event bus. Xenocept does not currently expose AeorDB’s event bus to plugins or external consumers. The Xenocept-level SSE streams above are the supported surface.

Frontend Event Bus (Maybe)

The frontend may have its own internal event bus that plugins can subscribe to (for in-page events like “the radial menu opened” or “a comment was committed”). If so, the contract for it lives in the frontend plugin host. This page won’t enumerate event names that aren’t visible from the Rust source, because there’s no way for this page to keep that list honest as the frontend evolves.

If you need to react to a specific UI event from a plugin, check the bundled plugins for examples or read static/components/ directly.