Website chat widget

The widget puts an agent on your website with one script tag. Visitors chat without signing in, the agent answers from your public knowledge, and conversations land in the Help Desk inbox when a person is needed.

Turn on Public widget on the agent's Channels step. Once the agent is saved, the step shows a Widget editor link. You can also start from Help Desk → Channels: click Add a channel, then Website widget.
The widget editor has five steps: Agent, Appearance, Messaging, Availability, Install. The header holds Save (or Create widget) and a Live or Draft pill.
On Agent, name the widget, pick Who answers first (AI assistant or Human only), and confirm the Answering agent. The step reminds you that anyone who loads a page it is installed on can chat with it.

The widget's handle and token are generated for you; the handle cannot be edited.

Install the snippet

On the Install step, copy the snippet and paste it before the closing </body> tag:

<script
  src="https://YOUR_RECORDS_LABS_HOST/widget.js"
  data-widget-slug="YOUR_WIDGET_SLUG"
  data-widget-token="YOUR_WIDGET_TOKEN"
  async
></script>

Save the widget first, then publish the site and test from the real domain. The script loads asynchronously and does not slow the page.

Rotate token issues a new token. Once you save, every copy of the old snippet stops working, so update your site right after.

Allowed origins

The token sits in your page source, so the widget only answers requests from sites you allow. The list is under Install → Advanced — access, identity & privacy → Allowed origins, one entry per line:

a domain, such as portal.your-domain.com
a wildcard, such as *.your-domain.com (sub-domains only, not the bare domain)
a full origin, such as https://portal.your-domain.com

Your organization's own websites already count: each entry in the Websites list on the Company details card (Knowledge → Business) is allowed with its sub-domains. Add entries here only for extra sites, such as a partner's.

www.example.com and example.com are separate entries. If the widget has no allowed origins and your organization lists no websites, it refuses to load everywhere. A site that isn't allowed gets "Origin is not allowed for this widget."

Appearance and messaging

The Appearance step sets the Accent color, Theme, the profile image, and the launcher: Style (Bubble, Pill, Tab, Glass, Liquid glass, Teaser pill), Size, Position, Icon and Launcher label, plus a Fine-tune group for shadow, animations, roundness and a Presence dot that follows your team's availability. Under Advanced you can hide the "Powered by" badge.

The Messaging step sets the Header title, Input placeholder, a Disclaimer, the greeting and starter prompts under Page experiences, a Proactive message, Where it shows, and Answer display options such as Show sources and the Confidence badge.

Verifying logged-in visitors

By default the widget answers from public knowledge only. To let a widget behind your own login use internal knowledge, or know who is asking, set Who can this widget answer for under Install → Advanced — access, identity & privacy:

Origin lock only: trusts pages on your allowed domains. No server work, but a technical visitor could bypass it.
Verified embedding: your server signs a short-lived pass on every page load, proving it holds your signing key.
Signed-in visitors: the pass also says who the visitor is. This mode can tailor answers to the visitor and unlock Gated knowledge by traits such as Plan and Customer tier.

For the last two, click Generate signing key and Copy it to your server. Rotate replaces it. The key must never reach the browser.

What to sign

A pass is two base64url parts (no padding) joined by a dot: the encoded JSON payload, then the HMAC-SHA256 of that encoded first part, signed with your key. The payload is JSON:

Required: slug (the widget's handle) and exp (expiry, Unix seconds). Keep expiry short, one hour is plenty, and mint a fresh pass on each page render.
For a signed-in visitor, add verification_level: "portal_authenticated" plus identity claims: external_id (or sub), email, name, phone, company, account_id, contact_id, and a traits object such as {"plan": "enterprise"}.
Optional: nbf, verification_method, verified_at, and a claims object.

account_id (or external_account_id) names the organization the visitor is acting for, and company is its name. While company requests are on for at least one of your gated Help Centers, a chat with such a pass is filed under that organization's own company in the Help Desk, created from company the first time the id is seen. It is never matched to one of your existing companies by email domain or name. See Customers and companies.

Delivering the pass

Add it to the script tag as data-signed-identity-token="…", or pass it after load:

window.RecordsLabsWidget.identify({ signed_identity_token: "…" });

identify() also accepts plain name, email, phone, company and external_id; unsigned details count as self-reported, not verified.

Records Labs has reference signers in Node, Python and PHP, and a Records Labs Widget plugin for WordPress; contact support for a copy. In WordPress, activate the plugin, open Settings → Records Labs Widget, paste the host, handle and token from your snippet, pick the mode that matches this setting, and paste the signing key.

In the Help Desk, a conversation's Visitor profile has a Verified attributes section. It describes the conversation's latest message: how it was verified (Anonymous, Self-reported, Verified by signed token, or Signed in through the customer's platform) and, for a signed message, the attributes that pass carried, such as its claims and account id. If the latest message came without a pass, the section shows Self-reported or Anonymous, even when the visitor was verified earlier. A reply the visitor sent by email or text message counts as self-reported. Under Verified embedding, the pass proves the page, not the person, so messages show Verified by signed token with no attributes.

If a Help Center behind a sign-in shows this widget, a visitor who signed in through your customer portal opens chat already identified. This needs two things: Who can this widget answer for is set to Public knowledge only, and the widget has a signing key. The Generate signing key button shows only under Verified embedding or Signed-in visitors, so pick one of those, generate the key, then switch back to Public knowledge only before you save. The key is kept. Visitors who signed in with an email magic link start chat unidentified.

The portal sign-in carries over as identity only. It never unlocks internal knowledge or Gated knowledge, and the portal's details (such as plan or role) show as verified attributes, not as visitor traits. Content you published for signed-in customers stays available, as it is on the portal's own pages. Inside the widget, a portal visitor gets an id of their own, so it never clashes with the external_id values your server signs. A person who chats both in the portal and on your own signed pages is matched by their verified email.

The Help tab

If your organization has a live, verified Help Center site, the Messaging step shows a Help Center section. Only a Help Center that is open to the public works here. If you pick one that requires sign-in, the Help tab stays hidden. Turn on Show a Help tab, choose the Help Center site, and set the Tab label (default "Help"). Visitors get a Chat / Help switch in the header, searchable articles, and an Ask about this article button inside each one. The tab is not shown on Human-only widgets.

Test before you publish

The editor's Live preview rail has a Design tab and a Try it tab. Try it works once the widget is saved and uses your real widget.
The Preview button on the Widgets list (the Widgets link at the top of the editor) opens a preview page. Anyone you share that link with must sign in as a member of your organization.
Capture visitor page context, under Install → Advanced — access, identity & privacy, records page URLs with conversations and respects Do Not Track and Global Privacy Control signals.

When a visitor leaves

If a person replies after the visitor has closed the page, the visitor can still get the reply by email. Turn on Email replies to offline visitors in Settings → Channels (under Help Desk); it only sends when the visitor's email is known. To let the visitor answer that email, an admin also picks a reply inbox in the Help Desk under Ticket Settings → Notifications → Reply Inbox. The email then carries that forwarded inbox as the reply address, and the visitor's answer lands on the same ticket. See Email inboxes and forwarding.