Skip to main content
Server events are JSON messages emitted on the control WebSocket. Historical events have a numeric id that is monotonic within the session.

Common envelope

Every historical event has this shape:
The remaining fields are placed at the same level as id, type, and time.

Session lifecycle

session.ready

Sent when the opening media is ready to play.
Start the player from playback.url. The playback URL is for this session; do not construct it yourself.

session.ending

Sent when a closing instruction or another terminal condition has started.
Stop sending new instructions after this event. A message that arrives after ending begins may be cancelled.

session.ended

Sent when the session is terminal.
Possible reason values are stopped, duration_limit, disconnect_timeout, and error.

Instruction lifecycle

instruction.received

The instruction has passed basic validation and entered the session queue.

instruction.scheduled

This is a current position estimate on the session video timeline. A later instruction.scheduled event can revise it.

instruction.started

The session playback position has reached the instruction’s start.

instruction.completed

The session playback position has reached the instruction’s end.

instruction.cancelled and instruction.failed

A failed or cancelled instruction does not apply state changes tied to its start or end.

Asset events

assets.added

assets.failed

State events

state.updated

Sent when one or more state changes become effective. The state object is the complete current state.
changes can include client_request_id and/or instruction_id for correlation. It does not include internal processing source information.

state.snapshot

Returned only to the connection that sent state.get. It is not part of the event history and has no id.

error

Errors are returned on the control channel as events and include the request id when one was supplied.
Use error.code for application behavior. Messages are short user-facing explanations and may change.

Ordering and reconnects

  • Process historical events in ascending id order.
  • Save the last processed id after handling an event.
  • Reconnect with ?last_event_id=<id> to receive events after that cursor.
  • Use state.snapshot.last_event_id to align a point-in-time state read with later events.
  • Unknown event types should be ignored safely so a client can remain forward compatible.