My Website

` is the mount point — the chat panel renders inside it and fills its dimensions. Style the div however you like (give it a fixed height, drop it inside a flex container, place it in a grid cell, etc.) and the chat panel will follow. You only need **one** ` ``` {% endcode %} The inline snippet carries it on the `

` instead, so one page can hold several chats going to different places: {% code overflow="wrap" %} ```html

``` {% endcode %} For an agent, the wording changes to `?agent=AGENT_ID` or `data-agent="AGENT_ID"`. A few things worth knowing: - Use the copy button rather than typing the ID by hand. If the ID doesn't match a campaign or agent on your account, the chat still works but falls back to your default routing. - Someone who is already mid-conversation stays with whoever they started with, even if they later land on a page pointing somewhere else. This keeps a conversation from switching personality halfway through. - A page-specific destination takes priority over your account default and over keyword triggers. ### Tell the Widget Who the Visitor Is (Advanced) If you put the chat widget inside a members area, a customer portal or an app where people are already signed in, your site already knows who they are. You can hand that over to the widget so the visitor isn't asked for details they've given you before, and so your AI can use what you already know about them. Add a small settings block **before** the widget script: {% code overflow="wrap" %} ```html ``` {% endcode %} Your page should fill those values in server-side, from whoever is logged in. Two things happen: - **The "Before we start..." form is skipped.** With a name and an email supplied, the visitor goes straight into the conversation, and those details are saved on their contact exactly as if they had typed them. - **Everything under `data` is handed to your AI.** Anything you put there — plan, order number, renewal date, credit balance, how many seats they have — becomes part of what the AI knows about that person, so it can answer "when does my plan renew?" without asking them to explain who they are first. Use whatever field names make sense to you; they show up on the contact under Custom Fields. Up to 20 values, sent fresh with every message, so if the plan changes mid-conversation the AI sees the new one. For inline embeds, you can put the same information on the `

` instead, which is handy when one page holds several chats: {% code overflow="wrap" %} ```html

``` {% endcode %} If your site only knows who the visitor is after the page has loaded — a single-page app where signing in happens without a page reload, for example — call this whenever you have the details, and the widget updates itself: {% code overflow="wrap" %} ```html ``` {% endcode %} A few things worth knowing: - If two different people sign in on the same computer, the second one starts a fresh conversation rather than seeing the first one's chat. The widget notices the change of person and resets itself. - On its own, this is for context, not for logging someone in. Conversations are still kept separate the way they always were, so passing an `id` doesn't let anyone open somebody else's chat, and someone using a different device or browser starts a new conversation there. To carry the conversation across devices, sign the `id` as described next. - It's optional. A widget on a normal public page needs none of this and behaves exactly as before. #### Resume the same conversation on any device (signed visitor ID) If your customers have accounts, you can make their chat follow them: sign in on a phone, continue on a laptop, and it is the same conversation with the same contact in your inbox, and the AI still knows everything that was said. For that, DM Champ needs proof that the visitor really is who your page says they are, otherwise anyone could type a customer number into their browser and read that customer's chat. The proof is a signature you compute on your server. 1. In the widget's **Manage** panel, under **Channels & Embed**, find **Signed-in visitors** and click **Generate secret**. Copy the identity secret. Keep it on your server only; never put it in the page itself. ::: master-only

The Signed-in visitors row in the chat widget's Manage panel, showing the masked identity secret with Show, Copy and Regenerate buttons, and the settings snippet with the id and hash fields underneath — The Signed-in visitors row under Channels & Embed. The secret stays hidden until you click Show; the snippet underneath shows where the id and its signature go on your page.

::: 2. When your server renders a page for a signed-in customer, compute an HMAC-SHA256 of that customer's ID using the secret, as a lowercase hex string: {% code overflow="wrap" %} ```js // Node.js const hash = require("crypto").createHmac("sha256", IDENTITY_SECRET).update(customerId).digest("hex"); ``` {% endcode %} {% code overflow="wrap" %} ```php // PHP $hash = hash_hmac('sha256', $customerId, IDENTITY_SECRET); ``` {% endcode %} {% code overflow="wrap" %} ```python # Python import hmac, hashlib hash = hmac.new(IDENTITY_SECRET.encode(), customer_id.encode(), hashlib.sha256).hexdigest() ``` {% endcode %} 3. Put the ID and the hash in the settings block, next to the name and email you already pass: {% code overflow="wrap" %} ```html ``` {% endcode %} The inline embed takes the same value as `data-visitor-hash` on the `

`, and `window.chatWidget.setVisitor({ visitor: { id, hash } })` works for apps that sign people in without a page reload. What happens once the signature checks out: - The customer's chat is stored under their account rather than under the browser, so it is the same conversation on every device and every browser where they are signed in, and one contact in your inbox. - Their earlier messages load on the new device, and the AI carries on from where they left off. - If the signature is wrong, the widget quietly behaves as it did before, as a normal per-browser chat, and prints the reason in the browser console so a developer can spot it. Your visitors never see an error. - The ID is compared exactly as you sent it, so sign the same value you pass as `id`, and use the same ID for the same person everywhere. Two things to know: - **Regenerate** in the Manage panel gives you a new secret. Pages still signing with the old one fall back to normal per-browser chats until your server uses the new secret. Existing conversations are kept; they are tied to the customer's ID, not to the secret. - A conversation someone had before signing in, as an anonymous visitor, stays a separate chat. The account-based conversation starts with the first message they send while signed in. ### Change the Widget Settings from Your Own Code (API) Everything on the widget's **Manage** panel can also be changed over the [REST API](../api/reference.md), which is handy if you manage many websites or want the attachment button switched off automatically for a client. Send a `PATCH` to `https://api.dmchamp.com/v1/chat-widget-configs/CONFIG_ID` with your API key and only the fields you want to change — for example `{"show_upload_button": false}` hides the attachment button, `{"show_emoji_button": false}` hides the emoji picker, and `{"launcher_icon": "chat-dots"}` swaps the launcher icon. `CONFIG_ID` is the same identifier as in your embed script. The full list of accepted fields (name, opening message, colours, launcher icon, allowed domains, visitor info form, privacy notice, theme, corner and font style) is in the [API Reference](../api/reference.md) under **Chat Widget**. Websites pick the change up the next time the page loads. ### What to Expect After Installation Once you've added the script to your website, the chat widget will automatically create a chat button in the corner of your website (bottom-right by default). The widget remains in a fixed position as users scroll through your pages, ensuring it's always accessible. ::: master-only

The floating chat bubble in the bottom-right corner of a live website, before a visitor has clicked it — This is what visitors see on your site before they open the chat — just the floating button, positioned per your Appearance settings.

::: When visitors click this button, it expands into a full chat window where they can start a conversation, showing your opening message. If Collect visitor info is on, a small form appears first asking for their name and email (and optionally phone) before they can type. ::: master-only

The opened chat panel showing the opening message in the background and the Before we start lead-capture form (First name, Email, Phone) in front of it — The opened chat panel. Here Collect visitor info is on, so the "Before we start..." form appears over the conversation — visitors fill it in once, then chat normally.

::: The chat interface adapts automatically to different screen sizes, so it works seamlessly on both desktop and mobile devices. ### Testing Your Implementation After adding the widget to your site, test that it works: 1. Open your website in a browser. 2. Click the chat button to open the widget. 3. Send a test message and confirm you get a reply. 4. Repeat on a different device or browser to confirm it works everywhere. ::: master-only

The chat panel after a visitor sends a test message, showing their outgoing message bubble underneath the opening message — After sending a message, it appears as an outgoing bubble in the thread — your AI or team replies in the same window.

::: If the chat widget doesn't appear on your site, check these: 1. Make sure you replaced `CONFIG_ID` with your actual configuration identifier. 2. Make sure the script tag is placed before the closing `` tag. 3. Check the code for typing errors. ### Behind a Corporate Firewall If the widget loads for the public but not for staff on the office network, the network is almost certainly blocking the domain it loads from. Ask your IT team to allow, over normal HTTPS on port 443: - **The domain in your embed snippet** — the address in the `