Allow the widget on your domains

What it is

Allowed domains is the list of websites that may use this chatbot's widget token. Two different questions, two different mechanisms:

• The token says which chatbot to load.
• The allowlist says which websites may load it.

Both must agree. That is what stops someone who copies your snippet out of your page source from running your chatbot — and spending your message credits — on a site you have never heard of.

An empty list is not "allow everyone". It means the widget has not been configured yet, and on a live site the widget is blocked everywhere until you list at least one host. An allowlist is required in production. This is deliberate: failing closed means a misconfiguration costs you a chat bubble, while failing open would let a leaked token run your chatbot on anyone's site.

When you would use it

Before you go live, and again every time you add a hostname: a new marketing domain, a staging environment, a regional site, a landing page on a different brand.

Where to find it

Open Dashboard → Chatbots → your chatbot → Integrations → Web widget, and scroll to Allowed domains (security).

Steps

1. Open Dashboard → Chatbots → your chatbot → Integrations → Web widget.
2. Find the Allowed domains box.
3. Enter one hostname per line.
4. Add every host visitors can arrive on. If your site answers on both example.com and www.example.com, list both — they are different hosts as far as a browser is concerned.
5. Add localhost if you test locally.
6. Select Save domains. Saving replaces the whole list, so edit rather than retype.
7. Reload your live site in a private window and confirm the bubble appears.

What a valid entry looks like

Enter bare hostnames. No scheme, no path, no port.

Write this	Not this
example.com	https://example.com
shop.example.com	shop.example.com/products
*.example.com	*
localhost	localhost:3000

Accepted forms:

• An exact hostname — example.com, shop.example.com.
• A wildcard subdomain — *.example.com matches example.com itself and any subdomain of it, such as shop.example.com and de.example.com. It does not match a look-alike like evilexample.com.
• localhost — for local development.
• A plain IPv4 address — for a dev or staging box reached by IP. An IP cannot be wildcarded.

Rejected: a bare *, anything with only one label (intranet with no dot), and numeric-only top-level domains.

If you paste something with a scheme, a path, or a port, the extra parts are stripped down to the hostname before the entry is checked. What is not silently accepted is an entry that is not a valid hostname at all — that is reported as an error when you save, so one typo cannot quietly brick a working list.

One wildcard or several exact hosts?

*.example.com is convenient and covers subdomains you have not created yet. That is both its advantage and its risk: if anyone in your organisation can create a subdomain, they can run your chatbot on it.

A reasonable rule:

• Exact hosts when you have two or three and they rarely change. Most businesses.
• A wildcard when you have many subdomains — regional sites, per-customer subdomains, preview environments — and the whole domain is yours and trusted.

You can mix both. Note that a wildcard only covers one domain: *.example.com says nothing about example.net, so a separate campaign domain always needs its own entry.

What you will see

A textarea with one host per line, a hint reminding you of the format and the 50-entry cap, and a Save domains button. When the list is empty, a warning tells you the widget is blocked on live sites until you list where it may run. If any entry is not a valid hostname, saving reports exactly which ones so you can fix them.

Connected WordPress sites also appear under Plugins → Connected websites, and connecting a site through the plugin adds its host for you. See WordPress plugin.

What the list does not cover

The allowlist applies to the script widget only. These are unaffected:

• The hosted page at /agent/{handle}. It is served by Agentency itself, uses no widget token, and needs no allowlist. If you want to restrict who can open it, that is a different feature — see Hosted page access control.
• The iframe embed of that hosted page, for the same reason.
• Messaging channels, which have their own connections.

So a Free workspace, which cannot use the widget at all, never needs to think about this list. See Iframe embed and direct link.

Limits and plan notes

Up to 50 hostnames per chatbot. The list is per chatbot, not per account — three chatbots on the same website each need the host added.

Editing this list needs permission to manage the widget or channels, which Editors and Admins have. See Roles and permissions.

The widget itself needs a paid plan with integrations.

Common problems

It worked on my laptop and failed after I shipped.

You listed localhost and never added the production host. Add the live hostname — and www if you use it — then save and hard-refresh.

I added https://shop.example.com/home and it still blocks.

Save the hostname only: shop.example.com. Scheme, path, and port are not part of a host.

It works on example.com but not www.example.com.

Different hosts. Add both, or use *.example.com to cover them together.

I cleared the list to "allow everything" and now nothing works.

That is the fail-closed behaviour. Add at least one valid host and save.

A subdomain stopped working after we launched it.

Exact entries do not cover new subdomains. Add it, or switch to *.example.com.

I saved and it still blocks.

Compare the address bar on the failing page with your list, character by character — a trailing typo, a regional subdomain, or a preview domain you forgot is the usual culprit. Then hard-refresh, since the page may be cached. If it still fails, work through Widget blocked.

Can I list a whole company, like *.com?

No. A wildcard covers subdomains of one registrable domain, and a bare * is rejected.