Skip to main content
This page documents the window.Revve JavaScript SDK (v2) that ships with the chat widget. It assumes the widget is already installed on your site — the embed snippet and RevveConfig setup live on Website Installation. Everything here is what you do after that: identifying visitors, controlling the UI programmatically, listening for events, and attaching metadata.
Widget look and feel — position, size, colors, launcher styling, teaser bubble copy, and visibility rules — is configured in the Website channel settings in the dashboard, not through the SDK. See Appearance & Styling and Bubble Messages. The SDK controls runtime behavior: who the visitor is, when UI shows, and what data attaches to conversations.

Boot contract

The embed script reads window.RevveConfig once at load: After the bundle loads it exposes a single callable global:
The SDK loads asynchronously, so window.Revve may not exist yet when your own code runs. If you call the API immediately at page load, add this queue stub right after setting RevveConfig — calls made before init are queued and flushed once the widget is ready:
The basic install snippet does not include the stub; you only need it if you call SDK methods before the bundle has loaded.

Identity and lifecycle

boot

Identifies the visitor and starts (or restarts) the widget for that user.
Behavior to know:
  • Calling boot again while already booted logs a console error and the call is ignored — unless you pass forceNewThread: true, which starts a fresh conversation thread (useful for a “new ticket” button). To switch users within the same page session, call shutdown first (or use forceNewThread: true).
  • If a persisted identity from a previous session differs from the new userId, the SDK shuts down first automatically before booting the new user.
  • contact requires name plus at least one of email or phoneNumber, and both are format-validated — an invalid contact aborts the entire boot with only a console error, so check the console if identification seems to have no effect.
  • contact is display-level data for the dashboard contact record — identification, not authentication.
  • token is a server-signed JWT and the recommended way to identify users securely. Verification happens server-side; when both contact info and a token are provided, the token takes precedence. See Visitor identity below.

shutdown

Clears identity and thread state, generates a new anonymous ID, hides all widget UI, and reloads fresh. Call this on logout — otherwise the next user on a shared device can read the previous user’s conversation.

update

Merges updated attributes into the current identity after boot. update is throttled to 20 calls per 30 minutes; calls over the limit are dropped with a console warning, so send meaningful changes, not every keystroke.

getAnonymousId / getVisitorId

Window control

showNewMessage accepts an optional string to pre-fill the composer; call it with no argument to open an empty composer.

Launcher control

These control the launcher button, not the chat window — distinct from show/hide above. Combine with the hideLauncher: true config flag to keep the widget invisible until your own UI triggers it.

Proactive bubbles

Only one bubble shows at a time. hideAfter auto-hides only when provided; without it the bubble stays until hidden. Set hideBubbleMessage: true in RevveConfig if you want full programmatic control and no dashboard-configured teasers firing on their own.

Notification sound

Replaces the default new-message sound with your own audio URL.

Metadata

Two scopes, two purposes — both persisted, both merged on repeat calls:
Use customAttributes on boot/update for facts about the user (plan, role); use metadata for facts about the conversation or session context. Metadata surfaces alongside threads in the Inbox.

Events

Register callbacks through the same command interface:
Event registration is append-only: there is no way to unregister a callback, and registering the same handler twice stacks it — it will fire twice. Register each handler exactly once, outside any code path that re-runs (SPA route changes, React effects without guards).

Visitor identity

The widget has three identity tiers:
  1. Anonymous (default). Every visitor gets a UUID stored in localStorage['revve_anonymous_id']. Conversations work fully; getVisitorId() returns this UUID.
  2. Identifiedboot with userId/email/contact. Convenience-level identification: the dashboard shows a real name and contact record, and getVisitorId() returns your userId. Nothing stops a visitor from claiming someone else’s ID from the browser console, so don’t gate sensitive data on it.
  3. Verified (JWT)boot with a token: a JWT your server signs with RS256 (upload the public key in the dashboard). The widget sends it for server-side verification, and it takes precedence over any plain contact info in the same boot call. This is the recommended path whenever the conversation can expose account-specific information. The same key setup backs the Bridge JWT configuration described in Chat Agent Advanced Settings.
Transitions: boot moves a visitor from anonymous to identified (their anonymous history is associated with the identity); shutdown drops back to a fresh anonymous ID.

Legacy API (window.revve)

The lowercase window.revve v1 API is deprecated and planned for removal in v3. Each call logs a deprecation warning. Migrate existing integrations and don’t build new ones on it:

Common patterns

Identify on login, shut down on logout

Hide the launcher on checkout pages

In a single-page app, run this on every route change — the widget doesn’t watch the URL for you.

Proactive bubble after 30 seconds on the pricing page

Pair with hideBubbleMessage: true in RevveConfig so dashboard-configured teasers don’t compete with your targeted one.

What’s Next