Reset Chat History

Reset Octocom whenever your website needs to discard the current chat and start a completely new browser session. For example, you might do this when someone logs out, changes account, completes a sensitive flow, or explicitly asks to start over.

Which reset should I use?

Reset chat history
├── Widget script is already loaded → dispatch the event
├── Reset must survive a redirect or the script may not be loaded → change the scope
└── Login, logout, or account switch → do both (recommended)

The event resets a widget that is already running. The session scope is a durable marker that the widget checks when it loads. Using both covers either timing.

Recommended website integration

Set a new opaque scope first, then dispatch the event:

function resetOctocomChat() {
  localStorage.setItem("octocom-session-scope", crypto.randomUUID());
  window.dispatchEvent(new CustomEvent("clearOctocomHistory"));
}

Call this when the customer logs in, logs out, or switches accounts. Keep the same scope during one login session—do not generate a new value on every page load. Scope values must be between 1 and 128 characters; a random UUID is recommended.

If your integration passes customer-specific data to Octocom, clear or replace it before resetting:

function startFreshChat() {
  clearCustomerData();
  resetOctocomChat();
}

Octocom does not automatically remove octocom:data:* values because those values are owned and managed by your website.

If the page redirects immediately afterward, the scope remains in localStorage. If the event listener was already loaded, the event also clears the current widget synchronously before the redirect.

What the reset does

The widget immediately:

• Removes the persisted Octocom browser-session ID.
• Discards visible and in-memory conversation history, including any response currently streaming.
• Clears cached conversation data so it cannot repopulate the widget.
• Applies the same reset to other open tabs on the same website.
• Starts a completely new browser session if the widget is open. If it is closed, a new session starts the next time it opens.

Server-side cleanup of the previous session is also attempted, but the browser reset does not wait for that request. The old history is removed from the widget even if the network is offline or the API call fails.

You can safely dispatch the event when the widget is open or closed. If customer-specific data should also change, update that data first so the new chat starts with the correct context.

URL scope for native WebViews

A native app may need to reset the chat when the user logs out, even though no WebView exists at that moment. In that case, give each native login session its own opaque scope and include it whenever the app later opens the WebView:

https://example.com/chat?octocom-session-scope=550e8400-e29b-41d4-a716-446655440000

Octocom remembers the last scope locally. When a different scope is supplied, the widget discards its persisted browser-session ID before loading any conversation and creates a fresh browser session. Reusing the same scope preserves the chat when the WebView is closed and reopened during one login session. Omitting the parameter preserves the default behavior.

The localStorage and URL options represent the same kind of scope; the URL takes precedence when both are present. A scope is only a local reset marker and never replaces Octocom's server-generated browser-session ID. Generate a new opaque value for each login session, keep it stable during that login, and limit it to 128 characters. Do not use an email address, authentication token, or other personal or secret value.