# Organizations > The company layer: many workspaces, one bill, one policy. **URL:** https://inference.sh/docs/org/organizations **Last updated:** 2026-10-11 --- The company layer: many workspaces, one bill, one policy. --- ## What an organization adds An organization sits above workspaces and centralizes what companies need centralized: | Concern | Without an org | With an org | |---------|----------------|-------------| | Billing | Each workspace pays for itself | One org balance pays for every workspace | | Governance | Each workspace sets its own usage policy | One org policy governs all workspaces (workspaces can't widen it) | | Accounts | Everyone self-registers | Org admins provision managed accounts | | Visibility | Workspace or public | An extra **org** level: visible to every workspace in the org, invisible outside | Workspaces keep their own members, roles, namespaces, and resources. Departments map to workspaces and keep their isolation. For HTTP endpoints (`POST /orgs`, `GET /orgs/{id}/teams`, org admins, managed users), see the [Organizations API](/docs/api/rest/orgs). For capability checks in custom clients, use [`GET /teams/{id}/view`](/docs/api/rest/teams#workspace-settings-view). --- ## The organization workspace An organization is itself a workspace. Creating one creates a workspace of type **organization** (`type: "org"` in the API) with the organization's name and slug. That workspace holds what belongs to the company rather than to any one workspace: the balance and payment methods, the usage policy, and connections shared across the whole organization. The organization workspace appears first under the organization's name in the workspace switcher. Its members are the organization's admins. It cannot leave the organization, and it cannot be archived while any of the organization's other workspaces still exist. Treat it as the **company layer**, not where day-to-day product work usually lives. When it is selected in the workspace switcher, the **chats** list and **new agent** page show a short, non-blocking note suggesting you switch to a team workspace for chats and agents. Other pages are unchanged. --- ## Creating an organization Only the **owner** of a **standalone shared workspace** can create an organization from **settings → organization → overview** (personal workspaces do not get this flow). The form states that an organization is a **new workspace for your company** — billing, policy, admins, and single sign-on — and that department workspaces **join** it. You enter a **company name** and a permanent **organization namespace** (the organization workspace's username in the API). The namespace must be globally unique and cannot reuse your current workspace's username. If the name you type matches your workspace's namespace, the form explains that it is your workspace's name and asks for a distinct company name (for example `acme`). A **move {workspace} into this organization** checkbox is on by default. When checked, the app creates the organization and immediately attaches your current workspace ([`POST /orgs`](/docs/api/rest/orgs#create-organization) then attach via the org workspaces API). Uncheck it to create the organization first and attach workspaces later from **settings → organization → workspaces**. You become the **owner** of the organization workspace. If creation succeeds but attaching the current workspace fails (for example you are not that workspace's owner), the app reports that the organization was created and points you to the organization's **workspaces** page to finish adding the workspace — the flow is not treated as a failed creation. --- ## Org admins Org admins are the owners and admins of the organization workspace. They manage the organization's workspaces, people, billing, and usage policy from the **organization** group in settings, or directly from the workspace's own settings. Adding an admin takes their email; the workspace has no plain members, and the last owner can't be removed. ### Standing on member workspaces Your role on the **organization workspace** also sets what you can do on every **member workspace**, even when you are not on that workspace's member list: | Role on the org workspace | Effective standing on member workspaces | |---------------------------|----------------------------------------| | **Owner** | Owner-level: manage members and admins, vaults, archive, and other owner capabilities | | **Admin** | Admin-level: manage plain **members** only (not grant admin or owner) | This is **standing**, not roster membership. Org owners do not show up as owners in **settings → workspace → members** unless someone adds them there. **Last-owner** rules still look only at listed owners on that workspace — you cannot remove the last listed owner even when an org owner could otherwise act with owner standing. Org-wide billing and usage policy stay on the organization workspace. Member workspaces remain billed and governed by the org; standing does not move payment methods onto a department workspace. For integrators, [`GET /teams/{id}/view`](/docs/api/rest/teams#workspace-settings-view) and the `can` field on each workspace in [`GET /orgs/{id}/teams`](/docs/api/rest/orgs#list-organization-workspaces) use the same capability table as the API gates. --- ## Workspaces in an organization Org admins get workspaces into the organization two ways: - **Create** a workspace from the organization page. It's born inside the org, billed by it, and governed by its policy from the first moment. This is also the path for admins who are themselves managed accounts. - **Attach** an existing standalone workspace. This requires both an org admin and that workspace's owner (org admins can't annex workspaces they don't own). Attaching stamps the workspace's existing resources into the org so they can be shared org-wide. Detaching a workspace is the reverse and is a custody transfer: the org stops billing it, stops governing it, and loses org-level visibility into it. The workspace leaves with its work. Org admins only, and the action is audited. The organization workspace itself can't be detached. --- ## Managed accounts Org admins can provision accounts for their people (enterprise-managed users). Provisioning as a workspace **member** is open to any org admin (admin standing on member workspaces is enough). Provisioning as a workspace **admin** requires **`manage_admins`** on the target workspace — the same grant as promoting someone to admin. An org **owner** has that standing on every member workspace without joining the roster; an org **admin** (admin on the org workspace only) must provision as a member first or ask an org owner. In **managed accounts**, the workspace picker only offers **admin** when the selected workspace grants you that right (from each row's `can` on [`GET /orgs/{id}/teams`](/docs/api/rest/orgs#list-organization-workspaces)). Managed accounts: - land directly in a workspace in the org, with **no personal workspace** - sign in with email link or code like everyone else - cannot create workspaces or organizations of their own - are deactivated and reactivated by org admins, not deleted by the user **Org deactivation** is separate from a **platform ban** (staff suspension). Deactivating a managed account blocks sign-in and API access and revokes active sessions, but it only records an org-level suspension. Reactivating clears that suspension and does **not** lift a platform ban on the same account. Managed users who hit a platform ban see a generic suspension at sign-in; org deactivation tells them to contact an org admin. This keeps every account, and everything it produces, inside the organization's perimeter. Removing a managed account from its last workspace ends its access immediately. On **organization → overview**, the **managed accounts** count includes only accounts that can still sign in. Deactivated accounts stay on the **managed accounts** page but no longer increase that count. --- ## Billing The organization workspace is the payer: one balance for every workspace in the organization. Org admins manage it under **settings → organization → billing**, which is the workspace's own billing page. Members of workspaces in the org see that billing is handled by the organization, plus their own workspace's usage. Workspace-level plans and payment methods don't apply to member workspaces. The company **plan** lives on the organization workspace as its primary `team_plan` (self-serve Stripe checkout or a complimentary contract row). Those limits apply org-wide: member workspaces do not enforce a separate base tier while the org plan is active, and usage for pooled resources counts across all org workspaces. Add-ons bought from the organization workspace are org-scoped too. See [Entitlements API — Organizations](/docs/api/rest/entitlements#organizations). **Prepaid credit top-ups** use the same payer boundary. From an org member workspace, the **add credits** modal (opened by a `payment_required` error), inline **add credits** controls (for example during engine onboarding), and other generic top-up entry points charge the **organization workspace** when you manage its billing. Stripe checkout returns to [settings → workspace → billing](https://app.inference.sh/settings/team/billing) on that payer workspace, where the session is settled. If the organization pays for the workspace and you cannot manage organization billing, the app shows the org notice instead of starting checkout. **Credit grants** (vouchers, bounties, and other prepaid credits) follow the same payer: they are stored on the organization workspace and usage across member workspaces debits that shared pool. See [Billing API — Credit grants](/docs/api/rest/billing#credit-grants).