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.
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.
Creating an organization
The owner of a shared workspace creates the organization from settings → organization → overview. The slug becomes the workspace's username, so it must be free in both places. The creator becomes the workspace's owner, and their current workspace joins the organization.
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.
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). 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
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.
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.
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 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.