One workspace, several sites
If you look after more than one website, most chat tools ask you to look after more than one account. Separate logins, separate billing, separate places to check whether anything came in overnight. It works until you have four of them.
onmsg organises the workspace around sites instead. A site is the unit that owns everything: its widget configuration, its conversations, its knowledge base, its flows and its team resources. You switch between sites inside the same workspace, and nothing crosses over. The knowledge you uploaded for one brand never surfaces in another brand’s answers, because it lives on a different site.
Common problems this solves
“Every client needs its own login.” One workspace, site switching, per-site separation. Add a site when you take on a brand rather than starting a new account.
“Our chat needs to live inside our own product.” Site-scoped API keys let a custom implementation ask the AI a question, read a conversation and hand a conversation into the human inbox, without embedding the widget at all.
“Our documentation changes weekly.” The knowledge source endpoints list, add or replace, and delete sources, so a pipeline can keep the knowledge base current without anyone opening the admin.
“We need per-client reporting.” Read site configuration and usage information through the API and pull it into whatever dashboard you already show clients.
What the API covers
The site API is deliberately small and specific. It can ask the AI a question and return an answer grounded in that site’s knowledge. It can read a conversation. It can hand a conversation into the site’s human inbox, which is the same handoff the widget triggers. It can list, add or replace, and delete knowledge sources. And it can read site configuration and usage information.
That set covers the two builds people actually want: a custom chat surface inside an existing product, and an automated knowledge pipeline. It is not a general-purpose platform API, and it does not replace the Shared Team Inbox, conversations handed over still land there for a person to answer.
Widget, API, or both
The chat widget is the fast path: a script snippet, a styling pass, and you are live. The API is the flexible path: your interface, your placement, your rules about when chat appears. Many setups run the widget on the marketing site and the API inside the logged-in product, sharing the same knowledge base and the same inbox.
When the multi-site structure starts to matter
One site needs no structure at all. The question is when the separation becomes worth thinking about.
At two sites, mostly convenience: one login, one place to check.
At three or four, separation starts protecting you. Different hours, different knowledge, different people answering. The cost of a mistake, one brand’s information surfacing in another’s chat, goes up with every site you add.
At five or more, it is the difference between a manageable arrangement and a collection of accounts nobody has audited in six months.
The API follows a similar curve. A single marketing site rarely needs it. A portfolio of client sites, or a business with a product surface as well as a website, usually finds at least one thing it wants to automate.
What to keep the same across sites
The temptation with several sites is to make each one different. Resist most of it.
Keep the operating pattern identical: the same flow shape, the same conventions for assignment and resolution, the same instinct to set grounding to Strict wherever prices are involved. Those decisions do not benefit from variation, and standardising them means anyone on your team can work on any site.
Vary what genuinely differs: the knowledge, the tone, the hours, the wording of every message. That is where the brands actually diverge, and it is where per-site separation earns its keep.
For a fuller breakdown, read what the onmsg site API can do and when to use the widget vs the API. If you are managing brands rather than building integrations, managing multiple websites and brands is the better starting point.
