Live chat (WebSocket)

No WebSocket on script load, launcher render, or typing alone.

mermaid

sequenceDiagram participant V as Visitor browser participant API as HTTP API participant WS as WebSocket API participant W as Worker V->>API: GET /widget/chatbots/{botId}/config Note over V: Show welcome + starters locally V->>API: POST /bootstrap (first message/starter) API-->>V: sessionToken + socketTicket V->>WS: $connect ?ticket= WS-->>V: chat.connection.ready V->>WS: chat.message.send WS->>W: enqueue chat_live_process W-->>V: typing + message.completed

Test Bot — HTTP only, shows confidence, routing, fallback reason (dashboard diagnostic).

mermaid

flowchart LR A[Test Bot] --> B[POST /chatbots/{id}/test] B --> C[Diagnostics visible] D[Test Real Chat] --> E[Live WebSocket client] E --> F[Same as visitor widget] F --> G[No diagnostics]

mermaid

flowchart TB HTTP[HTTP /message] --> RT[processChatMessage] WS[WebSocket worker] --> RT RT --> KB[Knowledge + intents] RT --> DB[(Messages + usage)]

Both transports call the same runtime — no duplicated chatbot logic.

mermaid

sequenceDiagram participant C as Client participant API as Bootstrap API participant WS as $connect C->>API: POST bootstrap (public key) API-->>C: single-use socketTicket (120s) C->>WS: ?ticket= (never secret key) WS->>WS: consume + bind origin/session

Never put secret_server keys in browser or WebSocket URLs.

If WebSocket connect fails, the widget/React client sends POST /widget/chatbots/{botId}/message with transportFallback: true. Billable messages still use chatbot_messages metering. Fallback count is tracked separately (non-billable).

mermaid

flowchart LR Bill[Billable] --> M[chat.message.send / starter] Free[Non-billable] --> P[ping/pong] Free --> T[typing/acks/deltas] Free --> S[socket open alone] Free --> R[reconnect attempts]

• Widget and React use @startupcore/chatbot-live-client internally.
• SDK: createLiveChatClient with widgetBootstrapFn + httpSendFn.
• See /chatbot/widget-script, /chatbot/react, /chatbot/sdk.