Put the widget on your site, and feed it what your page already knows.
Everything here is about running the agent on your own surface, rather than reading or writing your data.
Embed script
The one-line install, every data attribute it accepts, and the host-page context bridge.
Which surface do I want?
| I want to… | Go to |
|---|---|
| Put the chat widget on my site | Embed script |
| Install without writing code | One-click installs |
| Read or write my workspace data | API reference |
| Get notified when something happens | Webhooks |
| Wire it to other apps without code | Zapier |
No key needed
The embed script is public by design. It takes a chatbot id, not an API key — the id is visible in your page source and that is fine, because it grants nothing but the ability to chat with an agent you chose to publish.
Never put an API key in front-end code. Those are workspace-wide credentials.
Which domains can embed it
An agent can be locked to specific domains under Deploy → Allowed domains. With none set, the widget serves anywhere — which is the right default while you are testing, and worth closing once you go live.
Once you add a domain, the restriction is enforced by the browser: the agent's page carries a frame-ancestors policy, so it will not render in a frame on a site you have not listed, and the embed script paints nothing there. Two things it deliberately does not do. It does not restrict the agent's own hosted demo link, which is meant to be shareable. And it is not a defence against a determined script — an automated client that talks to our API directly is not a browser and is not bound by a browser's rules; rate limits and your usage caps cover that. Think of it as "this agent only runs on my sites", not "only my sites can reach this agent".