Domain — change the widget's allowed origin

Your account is locked to a primary domain — the site where the widget is allowed to run. Domain changes go through us: you submit a request with a short reason, we review, and we either approve or reject with a note. This page is where you start the request and check status.

Unlike per-API-key allowed origins (that's the multi-origin CORS list under API keys), the account domain is the canonical public-facing domain tied to your subscription.

Why this is a request and not a self-serve toggle

A domain change is rare enough that we'd rather review one than have someone accidentally swap their account onto a domain that isn't theirs. Most accounts never use this page; we built it for the cases where you actually do need to change — re-brand, re-domain, migrate from staging to production.

For day-to-day "I added a subdomain" changes, you want API keys → Edit origins instead. See API keys.

How to request a domain change

  1. Admin → Settings → Domain change.
  2. Request domain change.
  3. Enter the new domain — just the host, e.g. acme.com, no scheme.
  4. Write a short Reason. One or two sentences. Tell us what you're doing — rebrand, acquisition, splitting properties — so we can approve faster.
  5. Submit.

You'll see a row in the history with status Pending review. Only one pending request can be in flight at a time; if you want to change it, cancel and resubmit.

What happens after you submit

We get notified, look at the request, and either:

  • Approve — your account domain flips to the new value. The widget will load on the new domain (and stop loading on the old one) on the next config refresh, which is at most a minute or two for visitors on cached configs.
  • Reject — with a short note. Usually because the request looks ambiguous; resubmit with more context.

You'll see the status change on this page and (if you have it on) get a notification. The history list keeps every prior request — approved, rejected, and currently pending — so you've got an audit trail.

What about my API keys' allowed origins?

Different field. The account domain is one value. Each API key has its own list of allowed CORS origins — that's where you list acme.com, www.acme.com, staging.acme.com, and friends. The two interact: the account domain is the public-facing identity; the per-key origin list is the runtime CORS gate. See API keys for the origin-management UI and troubleshooting for the most common CORS errors.

Common questions

  • How fast is a domain change approved? Business hours; usually within a day. Submit something with no reason and we'll bounce it for clarification first.
  • Can I just edit the domain? No — that's the point. Submit a request.
  • My widget is broken because of a domain change. That's usually a CORS issue, not the account domain. Open the browser console; if it's complaining about the origin, edit the API key's allowed origins. See troubleshooting.
  • Can I have multiple domains on one account? The account domain is one value, but a single account can serve the widget from many origins — each API key has its own allowed-origin list. Use one API key per origin if you want them tracked separately in usage.
  • I rebranded. What do I do? Submit the new domain here, then swap your script tag to point at the right API key, then update each API key's allowed origins to include the new domain. The widget appearance / bot name / colors live in Widget → Appearance — this page doesn't touch them.

See also API keys for per-origin CORS allowlist, embedding for the script tag, and troubleshooting for the CORS-error walkthrough.

Where to find us

Stuck? Email [email protected]. Include the old domain, the new domain, and the reason — we can usually approve on the same thread.