ChatEvent

The SDK’s connection lifecycle has advanced or the channel mode resolved.

Fires after prepare(...) and connect() complete (the state transitions through .preparing → .prepared → .connecting → .connected → .ready), and again on any later transition (e.g. to .offline). The mode reflects the channel’s configuration (.singlethread, .multithread, .liveChat) and is stable for the session.

Consumers typically use this to gate UI: enable the “Open Chat” button at .ready, show an offline state at .offline.

A single thread changed — new messages arrived, the assigned agent changed, the thread name was updated, position in queue moved, etc.

Refresh the corresponding view (single-thread and live-chat channels). For multi-thread channels this also fires when an individual thread you are observing changes; if you only need the list, observe threadsUpdated(_:) instead.

The full thread list changed — a thread was created, archived, or its last-message preview was updated. Multi-thread channels only.

Refresh your thread-list UI.

The WebSocket connection dropped without an explicit disconnect() or signOut() call — e.g. the device lost the network, the server closed the connection, or a transport error fired.

The SDK does not auto-reconnect. Consumers typically retry connect() (possibly after a backoff) and surface a “Reconnecting…” state to the user.

A custom plugin message was received from the agent side. The raw payload is delivered as Data so consumer-side handlers can decode app-specific schemas.

An agent started or stopped typing in a specific thread.

Show or hide a typing indicator in the thread identified by threadId. The agent value carries the agent’s display info; isTyping == false indicates the agent stopped (no separate “stopped” event).

The currently active thread’s contact custom fields were accepted by the server.

Fires after a successful set(_:for:) call. Consumers typically use this as confirmation to dismiss a “saving…” indicator.

The customer’s custom fields were accepted by the server.

Fires after a successful set(_:) call. Consumers typically use this as confirmation to dismiss a “saving…” indicator.

The SDK encountered an error outside of an explicit try/throws call site — typically a server-side problem delivered asynchronously, a malformed event from the server, or a token-refresh issue that surfaced after connect() returned.

Consumers should surface the error to the user (or log + retry) according to their product’s error-handling policy. Errors here do not terminate the events stream; subscribers continue receiving subsequent events.

A backend-triggered proactive action arrived, such as an inactivity popup or satisfaction survey.

Switch on the associated value to present the action. Respond to an inactivity popup through trigger(_:); present a satisfaction survey using its prompt and URL over the conversation its threadId identifies — in multithread channels, hold it until the customer views that thread rather than presenting it over another one. CXoneChatUI currently handles both inactivity popups and satisfaction surveys automatically. Consumers building a custom UI on CXoneChatSDK directly must present both themselves. See cs-inactivity-popup.md for the inactivity-popup flow and cs-satisfaction-survey.md for the survey flow.