Overview

How panel events are delivered to websocket clients and how to consume them safely.

Panel events are asynchronous server-to-client notifications. Unlike regular usecases, they are not request-response packets initiated by the client.

Separate stream inside same socket

Panel events use the same websocket connection, but they can arrive independently of your request/response flow. Keep a dedicated event handler in your client loop.

How to enable panel events

Complete Initialize.

Send Set panel events subscription (type = 16) with subscribed = true.

Process incoming event packets while continuing normal request/response handling.

Event packet format

Server sends panel events as regular text JSON websocket frames:

{
  "id": 18446744073709551615,
  "event_type": 102,
  "content": {
    "version": "1.2.3"
  }
}

Prop

Type

Delivery and lifecycle notes

  • Panel events are delivered only while subscribed = true for this session.
  • Subscription state is preserved across valid session resumption. A brand-new session still starts unsubscribed.
  • Event frames can be interleaved with normal API responses.
  • For PanelEventDisconnect, PanelEventAppDeleted, PanelEventAppPaused, server sends event first and then closes connection with close code 4100, 4102, 4101 respectively.
  • Unknown future event_type values should be ignored gracefully for forward compatibility.
  • Packet to enable/disable stream: /websocket/packets/set_panel_events_subscription
  • Full event type table: /websocket/panel_events/event_types
  • Close code meanings: /websocket/close_codes

On this page