Why the allowlist rejected a site that looks like it is on the list

The widget does not appear, or a conversation fails to start, and the message names a site you were sure you had already added.

In rough order of how often each one turns out to be the answer. Work down rather than across: each carries a way to tell whether it is yours before you change anything.

• 1

  The apex and the www are different origins

  Why

  A browser treats example.com and www.example.com as two different origins, and the allowlist compares them as strings. Adding one does not add the other.

  How to confirm it is this one

  Open the widget and send a message. The rejection you get back names the origin in full, which the page-load console warning does not. Compare it to your list character for character. If one has www and the other does not, that is the whole problem.

  Fix

  Add both. Nearly every site serves one and redirects the other, but the redirect happens after the page has loaded somewhere, and the widget may well have run on the address before the redirect.

• 2

  The scheme differs

  Why

  The scheme is part of an origin, so an http page and an https page are different sites to the check even on the same hostname.

  How to confirm it is this one

  The rejection message names the full origin including the scheme. If it starts with http and your list entry starts with https, this is it.

  Fix

  List the scheme your site actually serves. If any part of the site is still on http, fix that first, because a mixed content page will produce other problems long before this one.

• 3

  A port is present on one side and not the other

  Why

  An explicit port is kept when the origin is normalised, so a development server on a port is a different origin from the same host without one.

  How to confirm it is this one

  The message names the origin including any port. Development origins are the usual case here.

  Fix

  Add the development origin separately, port included. It costs nothing and it is the difference between being able to test locally and not.

• 4

  A staging or preview host was never added

  Why

  Preview deployments, staging subdomains and platform preview addresses are all separate origins, and the widget is usually first tested on one of them.

  How to confirm it is this one

  The rejection names a host that is obviously not production. Platform preview addresses are the giveaway.

  Fix

  Add the ones you want it to work on. If preview addresses change per deployment, accept that the widget will not render on them and test on a stable staging host instead. There are no wildcards, deliberately.

• 5

  A subdomain was assumed to be covered

  Why

  There is no wildcard support at all. A subdomain is its own origin and has to be listed on its own line.

  How to confirm it is this one

  The rejected origin is a subdomain of a host that is on the list.

  Fix

  Add the subdomain. Wildcards are not supported on purpose: allowlisting every subdomain of a host that lets users create subdomains would be the same as publishing the key.

• 6

  The change has not propagated yet

  Why

  The configuration that carries the allowlist decision is cached for a minute, so a site added a few seconds ago can still be rejected.

  How to confirm it is this one

  Wait a minute, hard refresh, and try again before changing anything else.

  Fix

  Nothing to fix. This one resolves itself, and knowing that saves you from chasing a problem that has already been solved.

Two different messages exist and only one of them names the origin. On page load the console warning says the origin is not on the assistant's allowlist without saying which origin that was, because at that point the check is a flag on a cached response. The message you get when a conversation fails to start names it in full. So if you cannot tell which address was refused, open the widget and send a message: that is the path that tells you. Separately, an assistant with an empty allowlist accepts every origin, which is intentional so a new install works immediately, and it means an empty list is never the cause of a rejection.

What exactly does the message say?

It names the origin that was refused and tells you to add it under the assistant's allowed sites. Naming the origin is the point: without it, an agency installing on a client's staging domain has no way to work out which of several addresses was the problem.

Is the allowlist a security control?

It is a scope control. The publishable key is public by design, and the list is what stops a copied tag working on a site its owner does not control. It was never a defence against a script, which can send whatever headers it likes and still has to get past the visitor token and the rate limits.

Why does it work in the dashboard preview without being listed?

The dashboard is your own console, so previewing your own assistant there is explicitly permitted. Requiring people to allowlist their own dashboard to try the thing they just built would be a tax with no benefit.

Will wildcards ever be supported?

Possibly, and if they are they will be blocked at or below the registrable domain, because a wildcard on a host with user-created subdomains is indistinguishable from having no list at all.