Embedded widget

Soon

A drop-in chat panel for your own site. Not available yet.

Status

The embedded widget is not available yet, and this page exists so you don't build against something that cannot work today.

The frontend half is finished — there is a loader script, a configurator in the console, and a working chat panel. The backend half was never built. An embedded widget renders and then cannot answer anything, because the endpoints it calls do not exist.

Until it lands, the supported way to put a grounded chat on your own site is to proxy this API through your own server, as the examples in this documentation do.

How it will work

The design is settled. A customer pastes one script tag; it mounts an iframe pointing at a workspace, and the visitor asks questions of the documents the app owner curated. Visitors never sign in and cannot upload — the widget is read-only by design.

It will use a separate publishable key, not the API key documented here. That is the central constraint: a widget key is printed in the customer's page source, and the key on this site can delete workspaces and download every stored file. The two cannot be the same credential.

What's blocking it

Five things are outstanding, all server-side:

Three narrow, read-only widget endpoints — config, resources and chat.
A publishable key that authenticates those endpoints and nothing else.
An allowed-domains field on the app, so a lifted key can't be used from another site.
Server-side Origin validation. The frame-ancestors header the frontend already sets stops iframing, but it cannot stop a direct request.
Per-key rate limiting. A public key in front of a language model without a ceiling is an open invitation.

Status

The embedded widget is not available yet, and this page exists so you don't build against something that cannot work today.

Until it lands, the supported way to put a grounded chat on your own site is to proxy this API through your own server, as the examples in this documentation do.

How it will work

What's blocking it

Five things are outstanding, all server-side:

Three narrow, read-only widget endpoints — config, resources and chat.

A publishable key that authenticates those endpoints and nothing else.

An allowed-domains field on the app, so a lifted key can't be used from another site.

Server-side Origin validation. The frame-ancestors header the frontend already sets stops iframing, but it cannot stop a direct request.

Per-key rate limiting. A public key in front of a language model without a ceiling is an open invitation.