Skip to main content
Some people run one business. Some run several inside one account. And some run the same playbook for many businesses that do not share an account at all — a franchise, a network, a roster of clients who each pay their own bill. This page is for the third reader. It says plainly what exists today, what does not, and the direction we are working in — because a straight answer is more useful than an implied one.

​
What one account can already do

Workspaces are the built-in answer to “several businesses”. One account can hold as many as your plan allows, each with its own voice, look, connected channels and body of work. Nothing crosses between them, on purpose. See Accounts and workspaces. People sit on the account and are placed by role. One person can work across every workspace on it, and a client can be given a view of only what is shared with them. See People and roles. One bill, one credit balance. Everything made in any workspace on the account draws from the same balance, and Usage splits the month by workspace so you can see who spent what.

​
The reuse that exists today

Anywhere you are offered From a template, what you build is kept. An email design or a post shape you are happy with is yours to reuse rather than rebuild — see Emails and Posts. Where a workspace links a template held elsewhere on the same account, changes to it reach you: Settings → Notifications carries a Sharing & templates row for exactly that. And the Rules and sharing part of a Brand kit records what is settled and who else on the account draws on it — see Brand profile. That is the shape of reuse today: within one account.

​
Where the edges are

An account is a boundary, not a folder. Its plan, its people, its credits and its API keys stop at it. A key is tied to one account and cannot reach another. So the same material running in two accounts today means it is set up in each of them. The API works in one workspace per call. It never guesses which — you name one, pin the key to one, or set a default. Ask it for a group of workspaces and it refuses with workspace_set_unsupported and tells you to pass a single workspace, rather than doing something approximate. That refusal is the honest version of this whole page. Working across several workspaces at once exists in the product; naming such a group from the API does not yet. See Choosing a workspace and Errors and refusals.

​
Where this is heading

Two directions, stated as directions rather than dates:
  • Naming a group of workspaces, not just one. The refusal above already names the shape of the thing that is missing. Closing that gap is the work.
  • Material that is pointed at more than one place. Templates and the sets of work built from them are the pieces this would be assembled from, which is why they are built the way they are.
Neither is documented here as though it worked, and neither will be until it does. We write a page for a surface when it ships, never before — so the absence of a page is itself a reliable signal.

​
What to do in the meantime

  • Put each business in its own workspace where they share an account, and lean on templates and the Brand kit for the parts that repeat.
  • Keep a separate account per business where the bill, the people or the data must stay separate — and expect to set up each one.
  • Narrow one API key per workspace you automate, so nothing can write to the wrong one. See Choosing a workspace.
  • Tell us what you are trying to run. What this becomes is shaped by the people running it now — see Getting help.