Widget security
Your bot key is public. This page explains why that is fine, and how to stop anyone from embedding your chatbot on a site you do not own.
On this page
What the bot key can and cannot do
The bot key is in your page source, so treat it as public. Every embedded chat product works this way. It is scoped to exactly one capability: starting and continuing visitor conversations with that one chatbot. It cannot read your leads, your analytics, your billing or your settings. Only your X-API-Key can do that, and it never touches the browser.
Domain allowlist
Under Advanced → Allowed domains, list the hostnames the widget may load on. Requests whose browser origin does not match are rejected.
| Entry | Matches | Does not match |
|---|---|---|
acme.com | acme.com | www.acme.com, app.acme.com |
*.acme.com | www.acme.com, app.acme.com | acme.com itself |
acme.com and *.acme.com | the apex and every subdomain | - |
To cover www, add the wildcard. Entries are stored as bare hostnames, so typing www.acme.com is saved as acme.com and will not match a www origin on its own. acme.com plus *.acme.com covers the apex and every subdomain, which is what a chatbot created from a website URL gets by default. Add your staging hostname too if you test there. localhost and 127.0.0.1 are accepted outside production without being listed.
The allowlist checks the browser-supplied origin, which a page running in another browser tab cannot forge. A non-browser client such as a script can send any origin it likes, so per-chatbot rate limits and quotas remain the layer that bounds abuse from those.
Conversations across subdomains
By default a conversation is stored per browser and per origin, so a visitor who moves from example.com to academy.example.com starts a new one. Browser storage cannot cross that boundary on its own.
Setting a session-sharing domain (for example example.com) makes the widget mirror the conversation identifier into a cookie scoped to that parent domain, so the conversation continues across every subdomain under it. Leave it unset to keep each origin independent.
What visitors are asked for
The widget never asks a visitor for a password or a payment detail. Contact details are only collected where you have enabled the lead form or the visitor volunteers them in conversation.
Visitor IP addresses are used for geolocation and abuse prevention and are never shown in the dashboard, included in a CSV export, or returned by the API. Those boundaries return geography only. Full detail is in the Privacy Policy.
Something here wrong or missing? Tell us and name this page. We will fix it.