> ## 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.

# Team seat quota and invite enforcement

> How Orbit counts team seats for your organization: a per-org numeric cap that counts live members plus pending invites, enforced at invite time, and how to raise it or free a seat.

# Team seat quota and invite enforcement

Every organization in Orbit carries a numeric **seat quota** — the maximum number of people who can belong to the workspace at once, counting both live members and pending invites. The invite flow enforces that quota on every invitation, so when your invite is refused with a 422 you know exactly which counter tripped, and when you plan onboarding you know exactly which seats you still hold.

This page governs **how many members** may join. For **what each member may do**, see [Roles, teams, and permissions](/concepts/roles-teams-permissions). For how the organization itself sits in the tenant hierarchy, see [The subaccount organization model](/concepts/subaccount-organization-model).

## Section 1 - The organization's seat quota

The quota is a single integer on the organization record. A brand-new workspace starts with **2 seats** — the value mirrored in the plan catalog it is onboarded under, so what the plan page advertises as `limits.team_members` is what the invite flow enforces. From then on the quota is the org's own setting, not a plan-managed constant.

Two counters run against it:

* **Live members** — every active member record. Soft-deleted members no longer occupy a seat.
* **Pending invites** — every outstanding invitation. A pending invite reserves the not-yet-seated spot, so the same seat cannot be promised to two people while an invite is waiting on acceptance.

The quota is a seat **count**, orthogonal to role-based access control. It decides only whether one more member may join; it says nothing about which role the new member holds or which routes that role reaches. RBAC gates capabilities; the seat quota gates headcount.

## Section 2 - Where the value comes from

Three surfaces can set the quota, in increasing order of privilege:

| Surface                     | How the value lands                                                                                                                                                   |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Plan default**            | A new workspace inherits the plan catalog's team-seat figure (2 on the default self-serve path) written onto the organization at provisioning.                        |
| **Subaccount provisioning** | A parent organization creating or patching a subaccount passes `max_team_members` explicitly (1–500) in the subaccount request body.                                  |
| **Admin operation**         | Platform staff patching a tenant's editable fields set `maxTeamMembers` (1–10000) directly — the support path when a customer needs more seats than any plan assigns. |

A null value never survives into a gate decision: any read of the quota defaults back to 2, so an organization row missing the value behaves exactly like a fresh workspace.

## Section 3 - Enforcement at invite time

The seat check runs on every invite-create request, before the invitation record is written, the dedup token is minted, or the email is sent. The formula is one comparison:

```
liveMembers + pendingInvites >= maxTeamMembers  →  refuse
```

When it trips, the whole batch item is declined with a `422` and code `TEAM_MEMBER_CAP_REACHED`, with a message telling you how many seats your workspace includes and how to free one. The check degrades open on an unreadable database read — the quota gates invites, not billing, so a missed gate is a tolerable over-serve rather than a blocked team flow.

To free a seat, either:

* **Remove a live member** — the seat is available again immediately.
* **Cancel a pending invite** — the reserved spot returns to the pool before the invitee ever accepts.

Raising the quota is a parent-scope or platform-staff action per Section 2; a member of the organization cannot raise their own ceiling.

## Section 4 - How this differs from role-based access

The seat quota and the role hierarchy answer different questions and are enforced at different layers:

* **The seat quota counts heads.** It is checked once, at invite time, against a per-org integer. The [roles and permissions model](/concepts/roles-teams-permissions) never consults it — a route gate admits or denies on role alone, with no headcount arithmetic.
* **Roles decide what a member can do.** They are checked on every request, per capability. The seat check does not constrain which role an invite assigns — it only decides whether the invite may exist.

In the [subaccount model](/concepts/subaccount-organization-model), each organization in the tree carries its own quota. Inviting into a child organization consumes the child's seats; the parent's quota is untouched.

## Cross-references

* [Roles, teams, and permissions](/concepts/roles-teams-permissions) - the capability sibling; the quota counts heads, roles gate capabilities.
* [The subaccount organization model](/concepts/subaccount-organization-model) - where each organization's quota sits in the tenant tree.
* [Tenant isolation](/concepts/tenant-isolation) - the hard boundary the quota lives inside.