Common rules
- Send one JSON object per WebSocket message.
- Keep
client_request_idstable when retrying the same logical request. assets.addreplays the original result when the same id and payload are repeated; a different payload with that id returnsrequest_conflict.state.updateignores a repeated request id after it has been accepted.instruction.createis 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.
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:
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.
Message validation
An invalid message receives anerror 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.