Source groups are named collections of sources inside a project. Reach for them when you need:
  • Docs versions — v1, v2, latest
  • Product lines — separate products sharing one project
  • Audience separation — public docs vs. internal runbooks

​
Create and assign groups

1

Create a group

In the dashboard, open Project → Sources → Groups and create a group with a name (and optional description) — e.g. v2.
2

Assign sources

When adding a source, pick the group it belongs to, and optionally tag it with a version label (e.g. v2, latest). One source belongs to at most one group.
3

Scope your surfaces

Decide, per widget/key/API caller, which groups it should answer from — see below.

​
Scope retrieval to groups

Public chat, search, form-deflect, and WebSocket requests accept an optional group_ids list that restricts retrieval to those groups:
The widget equivalent is data-source-group-ids="grp_a,grp_b", and the SDKs accept groupIds.

​
Lock keys to groups

Client keys can carry an allowed groups list (set when creating the key under Project → Integration Credentials). At request time the server intersects the request’s group_ids with the key’s allowed groups:
  • Requests can narrow the allowed set, never widen it.
  • A key limited to v2 can never retrieve v1 content, regardless of what the request sends.
  • Requesting a group outside the key’s allowed set is rejected with 403.
This is how you serve version-scoped widgets: one project, one group per version, one client key per group.

​
Keep everything fresh

Content-hash change detection means every strategy only re-embeds pages that actually changed.

​
Get notified when things happen

Set up outbound webhook triggers under Project → Settings → Webhooks to receive events like conversation.completed, ticket.deflected, and simulation.completed at your own endpoint. Every delivery is HMAC-SHA256 signed with an X-BeforeQuery-Signature header — verify it before trusting the payload.