Tenancy and Linked Accounts
How APIANT isolates customers via tenants and supports multi-location customer deployments.
An APIANT system has one main tenant — its own database, filesystem, and user directory. Customers live inside that tenant as accounts. When the system needs multiple tenants (a very large customer with isolation requirements, a tenant earmarked for future migration to separate hardware), each tenant is a fully separate database.
For most integrators, the unit of customer separation is an account, not a tenant. Customer isolation, deployment, ops — all of it is account-shaped.
Accounts don't share data
An automation in account Acme can't reach data in account Boring Co. Connections, credentials, executions — all of it stays scoped to the account where it lives.
Because accounts are isolated, the same automation can run in many customer accounts at once with no risk of data leaking between them.
Switching accounts when you build
If you build integrations for customers, you spend time crossing between accounts — building in your sandbox, deploying to a customer, supporting them when something breaks. The APIANT permission that allows this is called Switch Account. Claude uses it on your behalf when you ask it to do work in another account.
You don't navigate UI menus to switch — you tell Claude:
> Check the health of Acme Fitness's account today.
> Deploy this automation to all our customers.
> Help me debug the failing webhook on Boring Co.
Claude switches into the right account, does the work, and switches back.
Switch Account is a high-trust permission. Anyone with it can read any account's data on the system. Grant it only to users who need it for delivery or support work.
Linked accounts
Some customers have multi-location setups: a fitness chain with 30 studios, where each studio is its own account in the source system. APIANT models this with linked accounts — a parent account whose child accounts share credentials and coordinate state. The customer connects once, and Claude handles the per-location routing under the hood.
You don't write the routing logic. You ask for the multi-location automation in plain English, and the platform routes each event to the right location's account.
Templates
Productized integrations ship as templates: one canonical automation, deployed across many customer accounts in a single coordinated step. Each account gets its own copy with its own credentials and its own execution history. When you change the template, Claude rolls the change out to all the deployed copies; rollback works the same way.
See Publish and deploy for the deploy workflow.
When a separate tenant makes sense
Most customers are accounts inside the main tenant. A few situations warrant a dedicated tenant (a fully separate database):
- A very large customer whose data volume warrants isolation from the rest of the system.
- A customer earmarked for future migration to separate hardware — provisioning them as their own tenant from the start makes that migration painless.
- Compliance or legal requirements that mandate database-level separation.
Tenants are an architectural option, not a per-customer default.
See also
- Credentials — how credentials stay scoped per user per account
- Building with the Plugin → Ops & Support — cross-account monitoring and support work