Skip to main content
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

1

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.
2

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.
3

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.
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.

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.
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.
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 and the tool floor.

Appearance

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, not something you configure here.

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.
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.
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, 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.
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.
The better version of a pre-chat form, in most cases, is 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 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 — without waiting on anyone’s approval.
Build on web chat while Apple and Google verification run. A flow you author here never names a channel primitive, 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.

No channel fee

Web chat carries no carrier cost and therefore no channel fee. You pay for resolutions only. See Channel fees.

Next

Quickstart

The ten-minute path — web chat is the channel it uses.

AI agents

Give the widget something worth talking to.

Channels overview

What to connect after this one.

Inbox

Where the conversations land.