Skip to main content

​
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. For how the organization itself sits in the tenant hierarchy, see The 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: 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:
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 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, 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