# How it works

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

Product: Clad Widget SDK
Source: https://docs.useclad.ai/widget/how-it-works

---

Support Chat has three moving parts that work together:

1. **The SDK on your page.** You add a single `<script>` tag (see
   [Quickstart](#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](#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`](#theming-locale--z-index) and show/hide surfaces via
  [`features`](#feature-visibility-overrides-features) on your settings or
  `SupportChat.createChat`. This is what makes the widget match _your_ app, and
  it's the focus of the [Theming](#theming-locale--z-index) and
  [Brand & deploy](#brand--deploy-from-scratch) 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.)