> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Tenant isolation at a glance > The plain-language summary of how Devotel Orbit keeps every customer's data separate: a private database schema per organization, tenant resolution from your API key on every request, and per-record ownership checks where reseller families share a schema. # 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](/concepts/tenant-isolation) 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: | Yours, privately | Examples | | - | - | | Audience and sends | Contacts, messages, campaigns, segments | | Channels and senders | Sender pools, channel credentials, inbound routing rules | | Automation and AI | Flows, AI agents, knowledge bases | | Media and history | Recordings, inbox conversations, usage events | 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: 1. **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. 2. **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. 3. **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. Inbound traffic runs the same resolution in reverse: a message or call arriving at one of your numbers carries no API key, so the platform looks the number up in the catalog's number-to-organization map and delivers the event into your tenant. ## 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. Same schema does not mean open access. Sibling subaccounts share storage, but every surface inside it enforces ownership; across families the boundary is the schema itself. ## 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](/concepts/tenant-isolation): the full deep dive, including how schemas are provisioned, migrated, and repaired. * [Data placement and residency](/concepts/data-placement-and-residency): where your data lives geographically, and how residency combines with isolation. * [SOC 2 controls](/compliance/soc2-controls): the audited control text behind server-side tenant resolution. * [Number lifecycle](/numbers/lifecycle): ownership gating when a number moves between subaccounts. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.