What is the public website widget and how do we use it?

The embeddable Harriet widget lets visitors chat from your marketing or help sites with scoped knowledge, skills, and ticketing—without signing into Harriet.

The public website widget is Harriet’s embedded chat for pages you control (for example marketing site, product docs, or a public help center). Visitors can ask questions without logging into the main Harriet app, while you still control what Harriet knows and what it can do on that surface.

What it is

A small chat panel (typically bottom corner of the page) that talks to Harriet over your normal Harriet deployment.
Each widget instance is tied to a widget configuration your admins create: display name, colors, opening message, optional browser context hints, and which support groups receive ticket escalations from that widget.
Traffic is treated as a public session: answers come from knowledge and skills you allow for that widget, not from the full private employee experience.

Where you can embed it

Any HTTPS page on hostnames you explicitly allow for your organization (your IT or Harriet admin maintains an allowed origins list for the widget).
Common placements: pricing pages, documentation, status or contact pages, and campaign landing pages where you want instant Q&A.

You cannot load the widget from arbitrary untrusted sites if those origins are not on your allowlist—this reduces token theft and abuse.

How it works (high level)

Admin creates a website widget entry in Harriet (alongside other public surfaces). Harriet issues a widget id used in the embed.
Your site loads the widget script and passes your customer identifier and, when required, a signed configuration (for example to pin the widget to that id, pre-fill identity for escalations, or bind optional fields). Signing uses a secret your admins rotate from Harriet—treat it like an API key.
The visitor’s browser sends messages to Harriet’s chat API. Harriet checks origin against the allowlist and validates signatures when your setup requires them.
Harriet runs the conversation with widget-scoped skills and knowledge linked to that widget’s channel reference (the same mechanism used to scope documents and defaults for that surface).
If the visitor opens a ticket or confirms contact details, Harriet can route the thread to the escalation groups configured on that widget.

Authenticated vs anonymous visitors

Anonymous: The visitor has no Harriet login. Answers use public knowledge and tools only; attachments may use time-limited signed links for preview where supported.
Signed-in embed (optional): If your product passes a verified identity in the signed config, Harriet can personalise escalation (for example pre-filled email) while still respecting widget versus full app behavior your admins configure.

What you should configure deliberately

Knowledge scope: Publish or assign documents so the widget sees only what is safe and useful on the open web (no internal-only HR data unless your security review explicitly allows it).
Skills: Enable only skills appropriate for unauthenticated users (for example product Q&A, not “show my payslip”).
Escalation groups: Point tickets at the right inbox (sales vs support vs partner desk).
Copy and branding: Title, colors, and first message should match the page context so visitors know what the bot can answer.

Example

Your Payments docs site embeds the Payments help widget. A prospect asks “Do you support SAML?” Harriet answers from payments-scoped articles and docs. If they need a human, the escalation lands in Payments support, not a generic HR queue.

Guardrails

The widget secret and any signing keys must stay server-side on properties you control—never embed secrets in public JavaScript.
Re-review allowlisted domains when you sunset a site or sell a brand so old embeds cannot call your tenant.
Public widgets suppress some internal-only link styles in answers so visitors are not sent to login-only Harriet URLs they cannot use; plan content accordingly.