The web widget puts an AiHummer agent on your website as an embeddable chat
launcher. Visitors click the bubble, type, and stream answers back from the same
turn engine that powers every other channel.
The widget is served by the gateway itself at the /widget/ path, so there is no
separate service to run.
How the embed works
The widget is delivered in three layers, designed to stay isolated from your
page’s own styles and scripts:
A small <script> loader that you drop into your page.
A shadow-root launcher — the chat bubble and panel render inside a Shadow
DOM, so your CSS and the widget’s CSS never collide.
A same-origin iframe that hosts the actual chat surface.
The embed snippet
Add the loader script to any page where you want the agent available, typically
just before the closing </body> tag:
The loader is served from the same gateway that runs your agents, so the chat
surface is same-origin with the widget assets.
Endpoints behind the widget
The widget talks to two gateway endpoints:
POST /v1/web/sessionGET /v1/web/stream
POST /v1/web/session opens a web chat session.
GET /v1/web/stream streams the agent’s reply back over Server-Sent
Events (SSE), so responses appear token-by-token.
Configuration
Two settings must be in place for the widget to serve and dispatch correctly:
AIHUMMER_WIDGET_DIR — the directory of widget assets the gateway serves at
/widget/.
AIHUMMER_DEFAULT_WORKSPACE_ID — the default workspace that incoming web
sessions are dispatched into.
[!NOTE]
The widget is served by the gateway at /widget/; you do not deploy a separate
process for it. Terminate TLS at your reverse proxy as you would for the rest of
the gateway.
**The web widget puts an AiHummer agent on your website** as an embeddable chat
launcher. Visitors click the bubble, type, and stream answers back from the same
turn engine that powers every other channel.
The widget is served by the gateway itself at the `/widget/` path, so there is no
separate service to run.
## How the embed works
The widget is delivered in three layers, designed to stay isolated from your
page's own styles and scripts:
1. A small **`<script>` loader** that you drop into your page.
2. A **shadow-root launcher** — the chat bubble and panel render inside a Shadow
DOM, so your CSS and the widget's CSS never collide.
3. A **same-origin iframe** that hosts the actual chat surface.
## The embed snippet
Add the loader script to any page where you want the agent available, typically
just before the closing `</body>` tag:
```html
<script
src="https://your-aihummer-host/widget/loader.js"
async>
</script>
```
The loader is served from the same gateway that runs your agents, so the chat
surface is same-origin with the widget assets.
## Endpoints behind the widget
The widget talks to two gateway endpoints:
```http
POST /v1/web/session
GET /v1/web/stream
```
- **`POST /v1/web/session`** opens a web chat session.
- **`GET /v1/web/stream`** streams the agent's reply back over **Server-Sent
Events (SSE)**, so responses appear token-by-token.
## Configuration
Two settings must be in place for the widget to serve and dispatch correctly:
- **`AIHUMMER_WIDGET_DIR`** — the directory of widget assets the gateway serves at
`/widget/`.
- **`AIHUMMER_DEFAULT_WORKSPACE_ID`** — the default workspace that incoming web
sessions are dispatched into.
> [!NOTE]
> The widget is served by the gateway at `/widget/`; you do not deploy a separate
> process for it. Terminate TLS at your reverse proxy as you would for the rest of
> the gateway.
## Where to next
- For chat apps, see [Telegram](/en/v1.0/channels/telegram) and
[MAX](/en/v1.0/channels/max).
- For a native app, see [Mobile client](/en/v1.0/channels/mobile-client).
- For custom integrations, see [Generic inbound](/en/v1.0/channels/generic-inbound).