Tenant isolation at a glance
“Is my data separate from every other customer’s?” is one of the first questions any platform like Orbit has to answer. This page gives the short answer and the shape of the guarantee; the full tenant isolation deep dive carries the engineering detail behind each point. The short answer: yes. Every organization’s working data lives in its own database schema, every request is scoped to your schema by the platform rather than by anything you send, and the one place where related organizations legitimately share storage carries per-record ownership checks.The short version
- A private schema per organization. Contacts, messages, campaigns, conversations, recordings, and every other working record live in a database schema that belongs to your organization alone.
- A shared catalog for platform-wide facts only. The phone-number pool, inbound routing targets, and organization identity live in a shared catalog. It holds routing and identity records, never another customer’s working data, and every write to it passes an ownership check.
- Your API key decides what a request sees. On every authenticated request the platform resolves the key to one organization and scopes the request to that organization’s schema before any handler runs. A tenant identifier supplied by a client is ignored; the resolved organization always wins.
- Subaccounts are gated per record. Sibling subaccounts under one reseller share a schema by design, and each record inside it carries an owning organization; reads and writes check ownership on every call.
- Provisioning fails closed. While a new organization’s schema is being prepared, the API answers with a transient 503 rather than run a query against anything but your schema.
What lives where
Your organization’s schema holds everything you create, send, and receive:
The shared catalog holds the small set of platform-wide tables every
organization reads: the phone-number pool and its assignment to
organizations, inbound voice and message routing targets, and
organization identity itself. Reading the catalog is how a message
arriving at one of your numbers finds your organization. It is not a
window into any organization’s data, and mutating a catalog row always
passes an ownership check.
How a request reaches your data
Three steps, on every authenticated request:- Key to organization. The platform resolves your API key to exactly one organization and reads that organization’s tenant and readiness state from the catalog.
- Connection scoped to your schema. The request is opened against your organization’s schema before any handler runs. If the schema cannot be attached, the request receives a 503 at this point, before any data is touched.
- Handlers see one tenant. Application code only ever speaks to the resolved schema. Nothing in the query string, request body, or path can redirect the request to another organization.
Subaccounts and reseller families
Subaccounts under one reseller parent are separate organizations that share the parent’s schema by design, so a family can operate on a common dataset. Isolation between siblings is therefore per record, not per schema:- A subaccount reads and writes only records it owns; a sibling’s records answer 403.
- The parent can move capabilities between siblings, for example reassigning a number, with ownership checks on each action.
- A different reseller family is a different schema entirely and is not reachable by any key in your family.
What this means for you
- There is nothing to configure. Isolation is structural, not a setting, and it applies to the dashboard, the API, and inbound processing alike.
- Right after signup, a brief 503 while your workspace is provisioned is the fail-closed behavior above, not an outage; it clears within seconds.
- A 403 on a subaccount record you do not own is the ownership gate doing its job.
Where to go next
- Tenant isolation: the full deep dive, including how schemas are provisioned, migrated, and repaired.
- Data placement and residency: where your data lives geographically, and how residency combines with isolation.
- SOC 2 controls: the audited control text behind server-side tenant resolution.
- Number lifecycle: ownership gating when a number moves between subaccounts.