What the widget remembers: conversations and storage
For developers, in code: what the widget keeps on the visitor's device and for how long, how a conversation survives navigation and crosses a site family, and the one call that wipes it.
The conversation survives page navigation because the widget keeps it in the browser’s
localStorage, per origin, best-effort — a browser with storage disabled or full simply does not
persist, and nothing breaks.
Two keys, two clocks
| Key | Holds | Lives |
|---|---|---|
sa:widget:<code> |
up to 10 conversations of up to 50 messages each (the server’s conversation id, the transcript, a title), which one is active, whether the widget was open, the remembered mode (text or voice), when the greeting teaser was dismissed | each conversation 7 days after its own last activity; the session fields — open, mode, active id, teaser dismissal — 45 minutes after the last write |
sa:widget:prefs:<code> |
the dragged position, that the widget was ever opened, the chosen spoken language and whether it was chosen by hand, that the greeting was spoken, which proactive findings were shown on which path (at most 40 records) | no expiry |
So a visitor who walked away is not handed a days-old conversation back on the next visit — it
stays one press away in the card’s history list — while a visitor who reloads mid-chat lands back
in it. A stale conversation id (the server answers not_found) silently starts a fresh one. No
cookies, no sessionStorage.
History, for the visitor
The card’s clock button lists the device’s recent conversations — the first question and a relative time — with a ✕ per row; a pick makes that conversation the current one. Deleting is per origin and never touches the owner’s own record of the conversation.
Across a site family
localStorage does not cross origins, so a navigation to a sibling domain would lose the chat.
When an answer offers a page on another origin listed on the same widget key, the runtime appends
?sa-conversation=<token> to that link. The widget never moves a visitor to another origin by
itself: the visitor follows the link with a click (it opens in a new tab), or your own router
does. The widget on the destination exchanges the
single-use token once (GET /conversation), adopts the transcript, opens, and strips the token
from the URL so it cannot leak through history or a shared link. An invalid, expired (90 s) or
already-used token just starts fresh.
Wiping it
Shukai.clearHistory() forgets every conversation on this device and the remembered mode, ends a
live voice conversation, aborts a dictation and empties the composer. Call it at logout on a site
with its own login — there is no in-widget «clear all» for a visitor to press.
Shukai.clearUser() is a different call (User identity).
What is not stored
- the relayed user token — memory only;
- the page’s form values — they travel with a message only under the owner’s read mode, and are never written to storage;
- anything for attribution: the campaign a visitor arrived on rides the first message of a conversation and is not kept on the device, so a visitor who navigates before chatting loses it — the accepted price of not handing the owner a consent obligation.