Skip to main content
Client messages are JSON commands sent to the session control WebSocket. The current protocol keeps this page separate from Server events because the two directions have different responsibilities: the client requests an action, while the server reports what was accepted, scheduled, started, completed, or failed.

Common rules

  • Send one JSON object per WebSocket message.
  • Keep client_request_id stable when retrying the same logical request.
  • assets.add replays the original result when the same id and payload are repeated; a different payload with that id returns request_conflict.
  • state.update ignores a repeated request id after it has been accepted. instruction.create is not a deduplicated command, so do not resend it unless you intend to create another instruction.
  • Ignore fields that are not listed for the message type you are sending.
  • Server events have a separate numeric id; use that id for reconnecting.

instruction.create

Creates a new piece of story direction. It affects content that has not been published yet.

assets.add

Adds image or audio references to the live session. The batch becomes available only after assets.added.
Each asset must contain exactly one source: file_id or url. Names are unique within the session; use a new name when the image or sound should be replaced.

state.update

Applies state changes immediately or schedules them for an existing instruction.
ops is accepted as a batch. Supported operations are: when.type can be immediate, instruction_start, or instruction_end. The latter two require instruction_id when the target is not the instruction currently being created.

state.get

Requests a state snapshot for the current WebSocket connection:
The server replies with state.snapshot. This response is private to the requesting connection and is not added to the session event history.

session.stop

Stops the session immediately or requests a closing instruction.
For an immediate stop:

Message validation

An invalid message receives an error event. The server rejects the whole message or whole operation batch; it does not partially apply an invalid state_ops or ops list. See Server events for response shapes and lifecycle events. The page path remains client-events for compatibility with existing links.