Skip to main content
Use server mode when chat history must follow a signed-in customer across devices. The browser never receives your account-wide API-Token. Your backend authenticates the customer, finds or creates their active chat session, and mints a short-lived user stream token. Server mode works with Anonymous usage switched off, is not checked against allowed websites, and is not subject to message limits or the daily cap, and nothing is counted. History loads still have generous abuse throttles. See Security and limits.

What the browser calls

The browser calls only your own token endpoint and then, with the token your backend returned, the Osvi AI chat history load and the live WebSocket. The token is valid for one session and the user stream only (about 5 minutes); the SDK refreshes it through getToken(). It never holds your API-Token.

Session flow

  1. The browser calls your backend’s token endpoint.
  2. For a normal start, your backend calls Rails GET /v1/chat/session/active?customer_id=…&agent_uuid=… for the authenticated customer and agent.
  3. If Rails returns 404, create a session with POST /v1/chat/session using your server-held API-Token. When the SDK calls getToken({ newSession: true }), skip the active-session lookup and create a fresh session even if one already exists.
  4. Request POST /v1/chat/session/{id}/ws_token. Take sessionId from the active-session or create-session response; the token response supplies token, ws_url, and expires_at, which your backend returns as token, wsUrl, and expiresAt.
  5. The browser SDK connects to the returned wsUrl.
History follows the customer while their session is active. After a period of inactivity the session goes dormant, and the active-session lookup in step 2 no longer returns it, so your backend starts a new session. To keep older history visible, read the customer’s past sessions server-side and present them yourself.
The callback returns { sessionId, token, wsUrl, expiresAt }. It may receive { newSession: true } when the visitor selects New chat; your backend must then create a fresh session instead of reusing the active one.

Node backend sketch

The rails client in these sketches is an authenticated server-side HTTP client that returns the Rails status and JSON envelope. Keep its API-Token on the server; never expose it to browser code.

Python backend sketch

The rails client represents an authenticated server-side HTTP client. Preserve the Rails status and JSON envelope handling in your implementation. Welcome carousel images also load for logged-in chats when Anonymous usage is off.

Identity and rotation

A server-mode client belongs to one identity. Destroy it and create a new client when the user logs in, logs out, or switches accounts. The SDK stores no token, session id, or visitor id in browser storage in server mode. It asks getToken() again on startup, token rotation (about every 4.5 minutes while connected), reconnect after an unauthorized close, and when a new session is needed. Phone-shaped customer ids are normalized to +91…. Do not use the public visitor format (web: followed by 16–64 URL-safe characters) as a server-mode customer_id; Rails rejects it with 422 invalid_customer_id because it would be addressable on the public rail.