You are running one Chatwoot instance and you have more than one client on it. There is a design decision waiting for you, and it is easier to get right at the start than to fix later: do all the clients share a single Chatwoot account, or does each client get an account of their own?
Both work. One of them stops working as you grow, and the migration out of it is genuinely unpleasant.
What an account actually is
In Chatwoot, the account is the real boundary. Almost everything you configure belongs to one account and is invisible to the others: inboxes, agents and teams, labels, canned responses, automation rules, custom attributes, and reports.
That makes the choice less about tidiness and more about what you are willing to share between clients.
Shape A: one account, one inbox per client
Every client’s WhatsApp number becomes an inbox inside a single account. Your agents see everything in one place and switch between clients in the same sidebar.
This is the right shape when your own team is doing the answering. A shared agency support desk handling five clients benefits from one queue, one set of labels, and one report.
It stops being the right shape the moment a client wants to log in. Chatwoot can restrict an agent to specific inboxes, and that covers the honest-mistake case, but it is a permission setting inside a shared account – not a wall between tenants. Labels, canned responses and automation rules remain common, and anyone with administrator rights in that account can see every client in it.
Shape B: one account per client
Each client gets their own account on your installation. Their inboxes, their agents, their labels, their reports. Nothing leaks sideways, because the boundary is the one Chatwoot itself enforces everywhere.
You can still work across all of them: a single user can belong to several accounts and switch between them, so your own staff do not need separate logins per client.
The cost is setup. Every new client means an account, at least one user, and the inbox – plus whatever labels and canned responses you want them to start with. Done by hand that is tedious enough to discourage you from doing it properly.
Side by side
| One shared account | Account per client | |
|---|---|---|
| Isolation between clients | Permission setting | Enforced boundary |
| Client can log in safely | No | Yes |
| Reporting | Combined; per-inbox filtering | Naturally per client |
| Labels, canned replies, automations | Shared by everyone | Per client |
| Agents | One pool | Per account, same person can span several |
| Onboarding a client | Add an inbox | Scriptable via the Platform API |
| Offboarding a client | Unpick their data by hand | Delete the account |
| Fits | Your team answers for everyone | Clients answer, or data must stay separate |
The question that decides it
Whose customers are these?
If the conversations belong to your clients’ customers, the conversations belong in your clients’ own accounts. You are holding other people’s customer data, and “we set a permission so our agents cannot see it” is a weaker answer than “it is not in the same account” when a client’s security review asks.
If you are the support team and the client never logs in, one account is simpler and the simplicity is worth something.
Why per-account is less work than it looks
The objection to Shape B is always the setup, and the answer is that you do not do it by hand. On a self-hosted instance the Platform API – authenticated with a platform app token, separate from the normal account API – creates the account, creates the user, and attaches that user to the account with a role. The inbox itself is created through the ordinary account-scoped API, using an access token belonging to the account you just made.
Two APIs, one sequence – and it can sit behind the same button the client clicks to connect their WhatsApp Business Account. They authorise, and your code provisions the account, creates their login, creates the inbox against their phone number, and seeds the labels and canned responses you ship as standard.
Note that the Platform API is a self-hosting capability. If you are weighing hosted Chatwoot for multi-tenant work, this is the main thing you give up.
Three things to settle early
- Who holds the administrator role in a client’s account. If the client is an administrator they can invite their own agents – and also change settings you depend on. Pick deliberately and write it into the contract.
- What a new account starts with. Default labels, canned responses, business hours, automation rules. Decide the standard set once and provision it every time, or every client’s instance drifts into something bespoke.
- What leaving looks like. A client will eventually want their conversation history, or want you to delete it. Per-account makes both a clean operation. Work out the export before you need it in a hurry.
If you already picked the shared account
Moving a client out of a shared account into their own is not a setting. Their inbox, contacts and conversation history all carry account references, so it is a data migration – and the WhatsApp number has to be pointed at the new inbox, which means a gap on a live channel.
Self-hosting does give you a blunter option, since you have the database. But the references run deeper than the inbox row, so this is something to work out against a restored copy rather than against the instance your clients are using.
It is doable. It is just much more expensive than making the decision correctly on day one, which is the entire reason this post exists.
The short version
Your team answers, clients never log in, you want one combined view: one account, one inbox per client.
Clients log in, or their data has to stay separate, or you expect to grow past a handful: one account per client, provisioned through the Platform API so the setup cost disappears.
We build multi-tenant Chatwoot deployments on your own domain, with automated client provisioning and WhatsApp Cloud API onboarding. If you are deciding between these two shapes, get in touch.