> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tied.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Web chat

> Live in minutes with one script tag — the only channel that needs no verification, carrier or DNS.

Every other channel has a gatekeeper — Apple, Google, a carrier, a DNS record. Web chat has none. Paste a script tag and you are taking messages.

That makes it the right place to start even if it is not where your customers will ultimately live. Get your agent answering real questions on your own site this afternoon, while Apple and Google verification run for the next month.

## Install

<Steps>
  <Step title="Create the inbox">
    Create a web chat inbox and attach the AI agent you built. The inbox settings page generates a script
    tag carrying your own website token and base URL.
  </Step>

  <Step title="Paste the snippet">
    Drop it in before the closing `</body>` tag on any page you control. **Copy it from the settings
    page** rather than from documentation — it carries your own website token.

    ```html theme={null}
    <script>
      (function(d,t) {
        var BASE_URL="https://your-tied-instance.com";
        var g=d.createElement(t),s=d.getElementsByTagName(t)[0];
        g.src=BASE_URL+"/packs/js/sdk.js";
        g.defer=true; g.async=true;
        s.parentNode.insertBefore(g,s);
        g.onload=function(){
          window.chatwootSDK.run({
            websiteToken: "YOUR_WEBSITE_TOKEN",
            baseUrl: BASE_URL
          })
        }
      })(document,"script");
    </script>
    ```
  </Step>

  <Step title="Send a test message">
    Open the page and talk to it. No website handy? The inbox settings page has a live preview you can
    message directly.
  </Step>
</Steps>

<Note>
  The widget's global is currently `chatwootSDK`, inherited from the platform Tied is built on. A
  `tiedSDK` alias is planned; when it ships this page will change and the old name will keep working, so
  nothing you install today breaks.
</Note>

## Single-page apps

The snippet is safe to load once at app boot. The widget attaches itself to the page and survives client-side route changes — you do not need to re-run it per route, and doing so will produce duplicate widgets.

If your framework hydrates late, load the script after mount rather than in the document head.

## Identity verification

By default anyone on your site can start a conversation as an anonymous visitor. That is fine for pre-sales and general questions, and completely unsuitable for anything account-specific.

<Warning>
  **Without identity verification, a visitor can claim to be anyone.** If your agent will look up orders,
  change account settings or discuss anything private, turn on HMAC identity verification before you
  connect a single integration.
</Warning>

Identity verification signs the user's identifier with a shared secret on **your server**, so the browser cannot forge it. Once verified, the conversation is bound to a real contact, and the agent can act on their behalf.

This is the difference between an agent that can only answer general questions and one that can reach a `read` or `write_simple` resolution — see [what counts as a resolution](/pricing/resolutions) and [the tool floor](/agents/actions).

## Appearance

| | |
| - | - |
| **Brand colour** | Drives the launcher and the customer's message bubbles |
| **Position** | Bottom left or bottom right |
| **Launcher** | The bubble icon, and whether a label sits next to it |

<Note>
  **Theme isn't a dashboard setting.** There's no light/dark control on this tab — light, dark, or
  following the visitor's system setting is an SDK `run()` option set directly in the
  [embed snippet](#install), not something you configure here.
</Note>

## The greeting

An opening message the widget sends on its own — automatically, but only in reply to the visitor's
**first message**, not before they have typed anything. It never talks to an empty room.

It fires once per conversation, on that first message, not on every page view, so a visitor moving around your site is greeted once rather than repeatedly.

<Tip>
  **Write it as a question, not a welcome.** *"Hi, how can we help?"* invites a vague answer and a
  round trip. *"What can we help with — an order, your account, or something else?"* gets you a routable
  first message, which means the agent's first reply is already specific.
</Tip>

Two things worth knowing:

* **The greeting is not a resolution and never bills.** A conversation that is nothing but a greeting is [Tier 0 — never billable](/pricing/resolutions), whatever happens next.
* **Out of hours, say what happens next.** If your business hours are set, the greeting is the right place to say when someone will reply, rather than leaving the visitor to discover it from silence.

## The pre-chat form

A short form shown before the conversation opens. Every field is optional to *configure*; each one you add is a thing the visitor must get past before they can ask their question.

| | |
| - | - |
| **Fields** | Name, email, phone number, and any [custom contact attribute](/contacts/attributes) you have defined |
| **Required or optional** | Per field |
| **Header text** | One line explaining why you are asking |

<Warning>
  **Every required field costs you conversations.** A pre-chat form is a filter, and it filters out
  people who would have become customers as readily as people who would not. Ask for an email when you
  genuinely cannot answer without being able to reply later — and nothing else.
</Warning>

The better version of a pre-chat form, in most cases, is [identity verification](#identity-verification): if the visitor is already signed in to your product, you already know who they are. There is no setting to hide the whole form from them — instead, each field is suppressed automatically once identity verification already supplies it, so a signed-in visitor is never asked to retype their name, email or phone. They only see whatever fields you configured that verification does not already cover.

Fields collected here land on the contact record, so they are searchable and available to the agent on the next conversation too.

## Business hours

Business hours here are an inbox setting, not a global one — a sales widget and a support widget on the same site can keep different hours.

Out of hours you choose whether the widget stays open and queues the message, or tells the visitor when someone will be back. If your [AI agent](/agents) is attached, it keeps answering either way: hours govern what people can expect from your team, not whether the agent works.

## The place to prove a new agent

Because web chat has no platform gatekeeper, it is the only channel where you can prove a complete agent loop — including [proactive outreach](/agents/proactivity) — without waiting on anyone's approval.

<Check>
  **Build on web chat while Apple and Google verification run.** A flow you author here
  [never names a channel primitive](/agents/messages), so it moves to Apple Messages for Business on
  approval day without being re-authored. The queue is calendar time; this is how you spend it.
</Check>

## No channel fee

Web chat carries no carrier cost and therefore no channel fee. You pay for resolutions only. See [Channel fees](/pricing/channel-fees).

## Next

<CardGroup cols={2}>
  <Card title="Quickstart" icon="zap" href="/quickstart">
    The ten-minute path — web chat is the channel it uses.
  </Card>

  <Card title="AI agents" icon="bot" href="/agents">
    Give the widget something worth talking to.
  </Card>

  <Card title="Channels overview" icon="radio-tower" href="/channels">
    What to connect after this one.
  </Card>

  <Card title="Inbox" icon="inbox" href="/inbox">
    Where the conversations land.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.