c.l.cladDocs

How it works

View as Markdown

Architecture overview: how the SDK, hosted widget iframe, and Widget API fit together.

Support Chat has three moving parts that work together:

  1. The SDK on your page. You add a single <script> tag (see Quickstart) — there's nothing to bundle or install. The SDK exposes a typed, Promise‑based API and owns identity and lifecycle: who the current user is, and when the messenger boots, updates, or shuts down.

  2. The hosted widget UI. The chat interface itself renders inside a hosted iframe served by Clad — not on your page. The SDK communicates with it over postMessage. Because the UI lives in an isolated iframe, your CSS can never collide with it and your page never gains access to the session token; the iframe acts as a security boundary.

  3. The Widget API and your support platform. The widget talks to Clad's backend over HTTPS, plus a WebSocket for realtime updates. Messages a visitor sends become real conversations in your support inbox, and replies from your agents (or AI) stream back into the widget in real time.

In short: the SDK lives on your site and controls identity, the hosted iframe renders the conversation, and Clad's backend routes everything into your support platform — tickets, agents, and knowledge base.

Teams that live in Slack can also answer widget chats from Slack — each conversation becomes a thread in a channel you pick, and replies in the thread reach the visitor in the widget exactly like inbox replies. See Slack‑native support.

You reference each widget from your code with a workspaceId and widgetId. Two things live in two different places:

  • Presentation and behavior live in your install code — set the theme and brand via theme and show/hide surfaces via features on your settings or SupportChat.createChat. This is what makes the widget match your app, and it's the focus of the Theming and Brand & deploy pages.
  • Identity, access, and intake live in the dashboard — under Settings → Integrations → Web Widget you manage the widget's name, allowed origins, JWT secret, knowledge base, ticket forms, and identity rules. (Everything is also editable over the admin API for scripting.)