# How it works

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

Source: https://docs.useclad.ai/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.

You configure each widget once in your **workspace admin** (theme, launcher,
allowed origins, knowledge base, forms, identity rules) and reference it from
your code with a `workspaceId` and `widgetId`.