Architecture and flow

The parts

In your visitors' browser:

• loader.js – a small loading part of a few kilobytes. It reads the configuration, checks consent, draws a placeholder launcher in its final position (no layout shift) and creates window.ReactiveChat with a command queue. It does nothing else.
• The core (core.<hash>.js) – chat window, connection, masking of personal data, rules. It is only loaded once a trigger fires: the browser is idle, a mouse or finger on the launcher, an API command, a frustration signal from MousePlayer. Most visitors never open the chat and therefore do not load it straight away either.
• Modules on demand – product tours, privacy text, shop features; each only when it is needed.
• Isolation – everything lives in a closed shadow DOM; styles via constructable stylesheets, no inline scripts, no eval, no cookies.

At reactive.chat:

• Delivery at https://cdn.reactive.chat/ – loader, core, modules.
• Chat server at wss://ws.reactive.chat/rc_wss/ – WebSocket with protocol rc.v1; the same address with https:// for the HTTP fallback, offline form, uploads, privacy text and Smart Answer.
• Account at https://reactive.chat/app – project settings, design, knowledge base, your team's desk.
• Server API at https://reactive.chat/v1/ – REST and MCP for your backend.

On your side (optional):

• Your backend signs the identity of signed-in users, answers the customer data request, receives webhooks and calls the server API.
• Your proxy serves everything through a subdomain of your own (Own domain).

Flow of a page view

1. The browser loads loader.js (asynchronously, blocks nothing).
2. The loader reads data-rc-*, ReactiveChatSettings and queued boot calls, checks the site key and consent and draws the placeholder.
3. A trigger fires; the loader loads the core from the same directory.
4. The core takes over the placeholder and the queue and works through queued commands in order.
5. It opens the connection and sends init with the site key, IDs, language, consent, the signed identity if any, and page context.
6. The server checks origin, project and identity and responds with init_ok: design and texts from the account, rules, features, limits, the conversation history so far.
7. The widget is ready (event ready). It reports page changes in single-page apps by itself.

Flow of a question

1. The visitor writes; personal data is masked in the browser, and the message carries a unique ID.
2. The server stores it (it recognises repeats by the ID), masks it again and confirms with an echo.
3. The AI assistant searches your knowledge base – for order questions from a confirmed user, additionally through the customer data endpoint – and streams the answer. When it hands over to your team is set in your account (Manual).
4. In parallel, events go through a queue to webhooks and integrations. A chat never waits for them.

Versions and delivery

• loader.js has no version number in its name and is replaced on updates. Embed it from cdn.reactive.chat (or through your proxy) for that reason, not as a copy.
• The core is called core.<hash>.js; the hash comes from its content, and each loader knows exactly its own core. That way loader and core always match, and a core can be cached for a long time.
• The configuration (design, texts, rules, tours) comes from the server on every connection. Changes in your account need no new snippet; they take effect after a short time (depending on the setting, up to one minute).
• Protocol version is 1. New fields are added; unknown ones are ignored.
• ReactiveChat.version gives the version of the core once it has loaded.

Where to set what

• In your account: appearance, texts, start screen, rules, tours, A/B tests, AI persona (Customisation), team, knowledge base, channels (Manual).
• On the script tag: what should apply per page (Script tag reference).
• In your page script: identity, context, opening from your own elements (JavaScript API).
• On your server: signatures, customer data, webhooks, API (Identity, Customer data, Webhooks, Server API).

Next: Quick start