Install the chat widget on your site

The widget is one line of HTML. There is no account key to paste, no plugin to install and nothing to configure in the snippet itself — the script is served from your own workspace address, and that address is what tells us whose chat this is.

Two things have to be true before a visitor can write to you:

the domain your site runs on is saved in the workspace, and
the script tag is on the page.

Miss the first and the launcher still appears — it just refuses to open a chat. That is the single most common install problem, and the section on checking your work below says exactly what it looks like.

Open Widget in the console. The first field, Where the widget runs, is a list of the domains allowed to load your chat. Save at least one before anything else — the install snippet is not even shown until you do.

Write the domain as your visitors see it in the address bar: acme.com, or https://acme.com in full. Several domains go in one field, separated by a semicolon:

acme.com;staging.acme.com;shop.acme.com

The comparison is exact, and that is worth spelling out, because every rule below has cost somebody an afternoon:

What you save	What it allows	What it does not allow
`acme.com`	`https://acme.com`	`https://www.acme.com` — a different host
`www.acme.com`	`https://www.acme.com`	`https://acme.com`
`acme.com`	The site over HTTPS	The same site over plain HTTP
`acme.com`	Any page or path on that host	`acme.co.uk`, `shop.acme.com`

A domain with no scheme is read as https. If your site genuinely runs on plain HTTP, save it as http://acme.com.
Subdomains are not covered by their parent. Staging, a shop on its own host and www are each their own entry.
A non-standard port is part of the address — save http://localhost:3000 to try the widget on a development machine.
The combined list can be up to 1000 characters, which is dozens of domains — the limit is not something you will meet by accident.

Get it wrong and nothing breaks permanently: fix the entry, save, and reload the page — nothing is cached against you.

Step 2. Paste the script

The console shows the exact line under Add this script to your site. It looks like this, with your own address in it:

<script src="https://your-workspace.replium.chat/embed.js" async></script>

Paste it just before the closing </body> tag, on every page you want the chat on. On most sites that means one edit to a shared template or footer, not a change per page — in a CMS it is usually a "custom HTML" or "before </body>" field in the theme's settings.

Three things worth knowing about that line:

It carries no identifier of any kind. Your workspace is recognised from the address the script is served from, so there is nothing in the snippet to leak, rotate or get wrong when you copy it between sites.
async means it never delays your page. The script loads alongside your own, and the widget draws itself once it is ready.
Loading it twice is harmless. A second copy of the tag on the same page notices the first and stops.

Step 3. Check that it works

Open a page of your site in a normal browser window and look at the corner you chose:

The launcher button is there, in your workspace's accent colour.
Clicking it opens a panel with your header title and a greeting.
A test message sends, and the panel answers — with your auto-reply if it is on, or with a line saying the message is in if you switched it off.
The message is in Conversations in the console, within a second or two.

Then go back to the Widget page and read the last card, Check the widget is live. It reports what your own visitors' browsers have already told us — we never fetch your pages:

Green — your widget loaded, on the address named there, at the time named there. Read that address twice: if it is not the site you meant, the tag is on a different host than you think.
Amber, "we haven't seen your widget load yet" — nothing has loaded anywhere. Open a page carrying the tag and press Check again. If you have only just pasted the snippet, give your site time to publish first.
Red — your widget was loaded on an address that is not in step 1, and the card names it. That is the mismatch below, already diagnosed for you: add that exact address in step 1 and save.
Amber, "you've added … to your list" — what the red note turns into the moment you save that address. The fix is in place and there is nothing else to do: the next visitor who opens a page there turns the card green.

Your own knowledge base pages carry the same widget and do not count towards this — the card is about your site, not ours.

One caveat about the dashboard: Widget status: Live means a domain has been saved, not that the widget was ever loaded anywhere. The card on the Widget page is the one that knows.

When it does not work

The failure worth recognising is the second row: on a domain that is not on your list, the launcher is drawn, and the panel says the chat is temporarily unavailable. It looks like an outage and it is a configuration mismatch.

What you see	What it usually is
No launcher at all	The tag is not on that page — check the page source for `embed.js`, and remember the tag lives in the template, not in one page's content
Launcher opens, "Chat is temporarily unavailable"	This domain is not in the list, or is there in another form — `www` versus bare, `http` versus `https`, a port. The last card on the Widget page, Check the widget is live, names the exact address it was refused on
Works on the live site, not on staging	Staging is its own domain and needs its own entry
Works for you, not for a colleague	They are probably on the other form of the address (with or without `www`). Save both
The panel is empty of everything but the greeting	That is a new conversation with no messages yet — normal

What your visitors get

Answers from your knowledge base, before they write. If you have published articles, the panel offers a search field under the greeting: a visitor types a question, gets up to five matching articles, and reads one inside the panel without leaving your page. There is nothing to switch on — the field appears as soon as your knowledge base has an article in it, and steps aside once the conversation starts. If nothing helped, one tap carries what they searched for into the message box.
A chat that remembers them, in that browser. The widget generates an identifier for the browser on first run and keeps it in local storage, so a returning visitor finds their earlier conversations under History. There is no sign-in: clearing site data or moving to another device starts them fresh.
Replies in real time, and a sound if they have looked away. An operator's answer appears without a refresh, and the visitor sees when someone is typing. With the panel open, a short chime tells them an answer landed while they were on another tab or in another window — and stays quiet while they are actually watching the conversation, since they can already see it. A visitor who has closed the panel hears nothing: the widget stops listening when it is shut.
An answer the moment they write, before anybody on your team has read it. This is on out of the box and says whatever you tell it to — see Auto-reply below.
Attachments — up to 3 files per message, by dragging them onto the panel, pasting, or the paperclip button. A message is up to 5000 characters.
A full-screen sheet on phones. On a narrow touch screen the panel is not a small corner card but a proper sheet, so the keyboard and the conversation are not fighting over 300 pixels.
A "Powered by Replium" line at the bottom of the panel on the free plan. The paid plan removes it.

The panel's look comes from two places: Appearance on the Widget page (header title, and which bottom corner it sits in) and your accent colour under Branding. Text and icons on the accent switch between white and near-black automatically, so a pale brand colour stays readable rather than becoming a light-grey-on-white panel.

Optional: tell visitors when you are closed

The third card on the Widget page, Working hours, is off by default and does exactly one thing: it lets the widget say when you are back instead of leaving someone waiting in silence.

Messages sent outside your hours still reach your inbox. Nothing is blocked, refused or queued.
The visitor is told when you open in their own time zone, not yours.
A shift that crosses midnight is fine — set it to close earlier than it opens and the widget describes it as running into the next day.

Auto-reply: what they read before you get there

The fourth card, Auto-reply, is the one thing on this page that is on before you touch it. A visitor who writes gets an answer straight away, in your workspace's language, and it appears in the conversation as an ordinary message from you.

It holds two texts, and your working hours pick between them:

During working hours — what to say when somebody is around. "Thanks for writing! We're here and usually reply within a few minutes."
Outside working hours — what to say when nobody is. "Thanks for writing! We're closed right now - we'll reply here as soon as we're back."

Both start as ours. Write your own over either one — this is the place to name the answer time you actually keep — and leave a field empty to go back to the default. Up to 500 characters each.

Three things worth knowing:

It answers the first message of a conversation, not every message. It is a greeting, not an echo, and a visitor who writes again in the same chat is not greeted twice.
It does not count as an answer. The conversation still says Needs reply in your inbox, still counts towards the badge, and still triggers the waiting-visitor alert. Nothing about it lets a real question sink.
With no working hours set, everybody gets the first text — a workspace with no schedule is never "closed", so the second one is never sent.

Turn the card off and a visitor's message sits in silence until a person answers, which is how the widget behaved before this existed.

The Mirror address field exists for sites that must load everything from their own host. Point it at your server — say https://chat.acme.com — and the install snippet switches to that address.

It only works if your server forwards three things to your workspace address: /embed.js, /api/widget/ and /replium-files/ (the last one is where attachments come from). If you are not deliberately proxying, leave this field empty.