Custom domains

A workspace can be reached on addresses of your own instead of on engadin.ai. The widget script, the hosted chat page, the dashboard and the links inside CRM notes and notification emails all move with them.

You can add more than one, and give each agent its own. A workspace running three websites can put each on its own address — chat.example.com, chat.example.net, chat.example.org — with every agent’s links naming the address that belongs to it.

Workspace → Deploy → Your domains. Any workspace admin can do this; nothing here needs the operator.

Two kinds

A subdomain of the platform — yourbrand.engadin.ai. Nothing for you to configure. It is live within about a minute of adding it, and it is the fastest way to get the platform’s own name out of your CRM links.

Your own hostname — chat.example.com. One DNS record, and your domain does not move anywhere: it stays with whatever provider hosts it today, and nothing else on it is touched.

Setting one up

1. Add it in the dashboard. Deploy → Your domains → type the hostname. If your workspace has more than one agent, choose which one it serves, or All sites.

2. Create the DNS record, if it is your own hostname. The dashboard shows the exact record; it looks like this:

   chat.example.com   CNAME   saas.engadin.ai

   A subdomain of the platform needs no record at all.

3. Wait for it to go live. Press Check to see where it stands. Once DNS resolves, the certificate is issued automatically, usually within a few minutes. Nothing else is required from you or from us.

4. Update your embed tags when convenient. Existing tags keep working, so this is not urgent.

Add the new one before you switch

A workspace holds as many domains as you like, and every one of them serves. So add the new address, wait for it to go live, and only then point your links at it. Nothing is ever briefly unreachable.

Which address a link uses

Every link the platform writes picks an address on its own. There are two kinds of link, and they follow different rules.

Links about one conversation — the transcript link in a CRM note, lead notifications, the email channel’s reply links. These use, in order:

1. a domain assigned to that agent, if it is live
2. a domain assigned to All sites, if it is live
3. engadin.ai

A domain assigned to a different agent is never used. A conversation from one website cannot end up linked on another website’s address, whichever domain your workspace leads with.

Links about your account — sign-in emails, weekly digests, health and anomaly alerts. These are not about one website, so they use the domain marked account links, then any other live domain in the workspace, then engadin.ai.

You do not need a catch-all

Leaving an agent without a domain of its own is fine. Its links fall to the next layer, and the last layer is always engadin.ai, which resolves to your workspace correctly. Nothing breaks if you assign every domain to an agent and keep none for All sites.

The one thing worth knowing: account emails then carry whichever domain is marked account links, which will be one of your brands. If you would rather they stayed neutral, add one domain set to All sites and mark it account links.

A domain that is not live yet is skipped at every step, so a link never points at an address that cannot answer.

Changing which domain your links use

Mark a domain account links to make it the one account emails name. This only affects new links: everything already written keeps working, because the workspace keeps serving every domain it holds.

Removing a domain is the only thing that takes one out of service. When you remove one, it is retired but keeps answering, redirecting to where your workspace lives now, so /admin/#/… links inside old CRM notes and sign-in emails still land in the right place. Redirects use a 301 for page loads and a 308 for everything else, which is what keeps a widget still embedded from the old host working: a 308 preserves the method and body, so its chat requests survive the hop.

Retire late rather than early. Keeping a redirect costs nothing; removing one that is still embedded on a page costs you a dead widget.

What happens on your domain

Everything. The widget, /chat, /admin/, the API — the whole platform answers there, scoped to your workspace. Requests arriving on your hostname can only ever see your workspace’s agents; asking for another workspace’s agent id returns “unknown agent” rather than an answer.

A domain assigned to one agent boots that agent: its root shows a chat page for that website, and the hosted chat page there offers reviewer sign-in. A domain set to All sites boots your first agent.

The small files around the widget move too, which is easy to forget when switching hosts: widget.js, the analytics bridge widget-events.js and the hosted /chat page all answer on your hostname. Pointing every one of them at your domain is what keeps the whole embed first-party.

Why bother

• The script tag on your pages points at your own domain, which survives tracking blockers and content-security policies that treat third-party hosts with suspicion.
• Links in emails and CRM notes read as yours, and read as the right brand when you run several.
• Cookies and requests stay first-party.

The platform’s own domains

The same mechanism runs the platform. engadin.ai is primary, and the addresses it was reached at earlier still serve every endpoint identically, because script tags and API integrations out in the world name them. Only browser pages there redirect to the primary domain.

If you have a tag pointing at an older host, it will keep working. Update it when you next touch the page, not urgently.