Skip to main content
The chat embed is a self-contained IIFE bundle that drops the Waniwani chat into any website. It talks directly to app.waniwani.ai, so no backend proxy is required on your side.
Platform feature. The dashboard generates the embed snippet for your project. Open app.waniwani.ai to get yours, or read more about the Platform.

Quick start

  1. Open your project on app.waniwani.ai and copy the chat embed snippet from the project settings.
  2. Paste it into your site’s HTML, alongside a mount point where you want the chat to appear:
That’s it. The chat mounts inside your marker div via Shadow DOM (so its styles never leak into your page). The snippet carries identifiers only — your project token, the channel ID, and the API URL. Title, welcome message, placeholder, suggestions, thread history and tool-call display are never baked in: the embed fetches them from your channel at runtime, so changing them in the dashboard updates live sites with no redeploy. Theming is the exception — it has no dashboard equivalent and is set on the tag (data-theme) or in CSS. Don’t hand-author the snippet — the channel ID is issued by the Platform and required for the embed to route correctly.

Modes

The embed renders in one of two modes, set with data-mode on the <script> tag: Use inline when the chat is part of the page (a section, or the page hero). Use floating when it should be available everywhere without taking up layout space.
If you want React-component-level control over the inline mount, see Chat in React.

Sizing

Inline mode only — in floating mode the panel sizes itself. The embed fills its container. Give the <div data-waniwani-embed> a definite size via CSS, or set data-height on the script tag:
A container you leave unstyled is 500px tall. That default is written with :where(), so it carries no specificity and any rule you write beats it — including height: auto to let the chat grow with its content. A ResizeObserver mirrors the container’s max-height onto the embed so padding and borders are respected.

Overriding attributes

You can edit data-* attributes on the <script> tag to tweak behavior. Do it sparingly: an attribute set here permanently outranks the channel config the embed fetches from the dashboard (resolution order is dashboard → data-*init()), so a title pinned on the tag can no longer be changed by whoever owns the channel. Floating mode only: Per-URL show/hide rules for the floating bar are configured in the dashboard, not on the script tag. Leave the wiring attributes (data-token, data-channel-id, data-api, the script src) as the dashboard generated them. Beyond the data-theme preset and data-assistant-bubble, individual colors, fonts, and bubble shapes have no data-* equivalent — set --ww-* CSS variables instead. They inherit through the widget’s Shadow DOM, so declare them on [data-waniwani-embed] in inline mode, or anywhere on the host page (:root works) in floating mode, where there is no container of your own. See Theming & customization for the full variable list and deep-customization recipes. Full type definitions: EmbedConfig and ChatTheme.

Programmatic init

For runtime control (computing options dynamically, mounting on demand), drop the data-token attribute from the script tag and call init() manually. You still need the wiring attributes from a dashboard-issued snippet:
init() returns an instance with destroy() and sendMessage(text). You can also call window.WaniWani.chat.destroy() and window.WaniWani.chat.sendMessage("...") directly on the global. init() also accepts an onEvent callback that mirrors chat lifecycle events (opens, messages, errors, link clicks) into your own analytics — Amplitude, Segment, gtag — with your page’s identity attached automatically. See Widget events (onEvent). By default the embed mints its own anonymous visitor id, a stable opaque value persisted in the browser’s localStorage. It rides on every chat request and tracking event, so a visit is attributable before the first message mints a session (see Sessions). If your site already tracks visitors with PostHog, Amplitude, Segment, or a first-party cookie, override that id with your own. Waniwani then correlates its sessions and events to the same visitor you see in your analytics, and your server-side MCP tools and flows read the id back as context.waniwani.visitorId, so they can send events straight to the same analytics tool the id came from. There are three ways to set it. Pick the one that matches when your id is available.

If you know the id up front

Set it declaratively on the script tag:
Or pass it to init() when you initialize programmatically. init() accepts a string or a resolver (sync or async), so you can read the id inline:

If the id resolves asynchronously (the common case)

Analytics SDKs usually assign a distinct id only after they bootstrap, so read it when it’s ready and hand it to the widget. setVisitorId() is safe to call at any time, before or after init(), and the new id applies to the next chat request and tracking event:
A blank value is ignored, so an id that isn’t ready yet never wipes a good one. Read the id the widget will send with window.WaniWani.chat.getVisitorId().
The visitor id identifies a device / browser, not a signed-in account. When a visitor logs in, keep the visitor id and additionally call identify() with your account id, so anonymous and known activity stitch together.

Self-hosting the JS bundle

If you’d rather not load from a CDN, pin a specific SDK version and serve the bundled file yourself. The data-* attributes still come from the dashboard snippet — you’re only swapping where embed.js is served from:
Then point the dashboard-issued snippet at your local copy:

How it works

  1. The script reads its own data-* attributes (token, channel ID, mode, theming, content overrides).
  2. On DOMContentLoaded (or immediately, if the DOM is already ready), it mounts the chat via Shadow DOM — inside [data-waniwani-embed] in inline mode, or in its own anchored container in floating mode.
  3. The chat calls app.waniwani.ai/api/mcp/chat with the project token and streams responses back through Server-Sent Events.
  4. Conversation history lives only in memory by default; set data-enable-thread-history to persist threads in IndexedDB on the user’s device.
No server-side integration on your side.