# Manage Multiple Sites + Chat API | onmsg

> Manage multiple websites and brands from one workspace, each with its own config, conversations, knowledge, flows and team. Site-scoped API keys for custom integrations.

URL: https://onmsg.app/features/multi-site-api/

# Run chat across several websites, plus an API for custom builds

Last updated: September 8, 2026

One workspace organized around sites, with per-site configuration and a site-scoped API to ask the AI, read conversations, hand off, and manage knowledge.

-   Sites as the organizing unit, with switching and separate config, knowledge, flows and team
-   Site-scoped API keys for custom implementations
-   API: ask the AI, read a conversation, hand off to the inbox

Start free

[https://chat.onmsg.app →](https://chat.onmsg.app)

 

See what's in each plan

[/pricing/ →](/pricing/)

No credit card required

![One workspace switching between several website chat configurations for different brands](/images/misc/modern-3d-illustration-of-one-workspace-switching-.webp)

-   Grounding controls, not guesswork
-   11 flow step types, no code
-   Shared inbox with handoff
-   Start on the free plan

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

![A site switcher panel showing separate knowledge, flows, conversations and team per site](/images/misc/modern-3d-illustration-of-a-site-switcher-panel-wi.webp)

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

[/features/shared-team-inbox/ →](/features/shared-team-inbox/)

, conversations handed over still land there for a person to answer.

## Widget, API, or both

The 

chat widget

[/features/website-chat-widget/ →](/features/website-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

[/guide/what-the-onmsg-site-api-can-do/ →](/guide/what-the-onmsg-site-api-can-do/)

 and 

when to use the widget vs the API

[/guide/when-to-use-the-widget-vs-the-api/ →](/guide/when-to-use-the-widget-vs-the-api/)

. If you are managing brands rather than building integrations, 

managing multiple websites and brands

[/guide/managing-multiple-websites-and-brands/ →](/guide/managing-multiple-websites-and-brands/)

 is the better starting point.

Product tour

## Multi-Site & API in the product

Clearly labelled example views of the screens involved.

![A site list in a workspace, each row showing its own widget configuration and status](/images/misc/modern-3d-illustration-of-a-site-list-in-a-workspa.webp)

Sites are the organising unit, each with its own configuration.

![Site-scoped API keys being generated and listed in a settings panel](/images/misc/modern-3d-illustration-of-site-scoped-api-keys-bei.webp)

API keys are scoped to a single site.

![An API request asking the AI a question and returning a grounded answer payload](/images/misc/modern-3d-illustration-of-an-api-request-asking-th.webp)

Ask the AI a question from your own application.

![Knowledge sources being listed, added, replaced and deleted through an API call](/images/misc/modern-3d-illustration-of-knowledge-sources-being-.webp)

Manage knowledge sources programmatically.

Why onmsg

## Why teams use onmsg for multi-site & api

One workspace organized around sites, with per-site configuration and a site-scoped API to ask the AI, read conversations, hand off, and manage knowledge.

### Sites don't leak into each other

Each site has its own configuration, conversations, knowledge, flows and team resources. A knowledge source added for one brand never turns up in another brand's answers.

### Built for people managing several websites

Agencies, franchise operators and anyone running more than one brand switch between sites in the same workspace rather than juggling separate logins.

### API keys scoped to one site

A key grants access to its site and nothing else, which keeps a client integration contained to the client it belongs to.

### Ask, read, hand off

The API can ask the AI a question, read a conversation, and hand a conversation into that site's human inbox, the three things a custom front end actually needs.

### Knowledge management without the UI

List, add or replace, and delete knowledge sources through the API, so a documentation pipeline can keep the knowledge base current on its own schedule.

### Configuration and usage you can read

Read site configuration and usage information programmatically, which is what you want when you are building a client dashboard rather than checking a screen.

## Managing several sites, compared

| Capability | Typical website chat tool | onmsg |
| --- | --- | --- |
| Accounts needed for 5 brands | One account per brand | One workspace with five sites and site switching |
| Knowledge separation | Shared or manually duplicated | Separate knowledge base per site |
| Flow separation | Shared flows across sites | Separate flows and configuration per site |
| API scope | Account-wide key | Site-scoped keys |
| Programmatic knowledge updates | Manual upload only | List, add/replace and delete knowledge sources via API |
| Custom front end | Widget only | Widget, API, or both together |

Questions

## Multi-Site & API FAQs

### Can I run several websites from one account?

Yes. The workspace is organised around sites, and you switch between them. Each site keeps its own configuration, conversations, knowledge, flows and team resources.

### Is knowledge shared between sites?

No, and that is intentional. Each site has its own knowledge base, so answers for one brand are never drawn from another brand's documents.

### What can the API do?

Ask the AI a question, read a conversation, hand a conversation into the site's human inbox, list, add or replace and delete knowledge sources, and read site configuration and usage information.

### Are API keys account-wide or per site?

Site-scoped. A key works for the site it was created on, which keeps client integrations contained.

### Should I use the widget or the API?

The drop-in widget covers standard installs and gets you running fastest. Use the API when you need a custom interface, want chat inside an existing product surface, or need to drive knowledge updates from a pipeline. Plenty of setups use both.

### Does the API replace the inbox?

No. It can hand a conversation into the site's human inbox, but the inbox is still where your team reads, assigns, resolves and replies.

### Is this suitable for an agency?

That is one of the main reasons it exists. One workspace, one login, one place to switch between the sites you look after, with per-site separation so client work stays separate.

### Can I see usage per site?

Yes, usage information is readable per site, both in the workspace and through the API.

## Related features

### Website Chat & Widget Customization

An embeddable chat widget you install with a script snippet, then customize to match your site: colours, fonts, placement, hours, and custom CSS.

Read more

[Website Chat & Widget Customization →](/features/website-chat-widget/)

### Grounded AI Agent & Knowledge Base

An AI agent that answers from your own knowledge base, with grounding modes, configurable refusals, and handoff to a person.

Read more

[Grounded AI Agent & Knowledge Base →](/features/grounded-ai-agent/)

### AI Provider Choice (BYOK)

Use platform-provided AI or bring your own provider key, with provider/model selection, key testing, a grounding probe, and usage reporting.

Read more

[AI Provider Choice (BYOK) →](/features/ai-provider-choice/)

![](/images/hero/modern-3d-illustration-of-api-endpoints-connecting.webp)

No credit card required

## Ready to set up multi-site & api?

One workspace organized around sites, with per-site configuration and a site-scoped API to ask the AI, read conversations, hand off, and manage knowledge. Start on the free plan and configure it on your own site.

Start free

[https://chat.onmsg.app →](https://chat.onmsg.app)

 

Compare plans

[/pricing/ →](/pricing/)

-   Free plan available
-   Installs with a script snippet
-   Your content, your controls