Authentication Model
Widget endpoints do not use bearer token authentication. Instead, they rely on a three-layer security model:- Assistant ID — Each request includes the assistant ID, which must have
widgetEnabled: true. - Domain allowlist — The
OriginorRefererheader is validated against the assistant’s configured allowed domains. - Session token — After initialization, a session token is returned and must be included in subsequent requests.
Widget sessions can be anonymous (no user identity) or authenticated (linked to a known contact via email or external ID). Anonymous sessions are converted to authenticated sessions when a lead form is submitted.
CORS and Domain Restrictions
Widget endpoints include appropriate CORS headers to allow cross-origin requests from approved domains.Initialize Widget Session
Creates a new widget session or resumes an existing one. This must be the first call made by the widget.
Response
200 OK
Send Message (Streaming)
Sends a visitor message and streams the assistant’s response via SSE. The streaming format is identical to the standard Chat API SSE events.Get Session History
Retrieves the full message history for a widget session.200 OK
Submit Lead Form
Captures visitor contact information. Converts an anonymous session into an authenticated session linked to a contact record.
Response
201 Created
Lead form submissions trigger the
contact.created webhook event if webhooks are configured for the workspace.Submit Feedback
Allows visitors to rate a conversation or a specific assistant response.
Response
201 Created
End Session
Explicitly ends a widget session. The session can no longer accept new messages after this call.200 OK