Organisationen, Teams & Abrechnung

UniAuth modelliert Teams und Unternehmen als eine einzige Organisationsentität. Dieser Leitfaden behandelt, wie eine Organisation erstellt wird, wie ihre Stufe entscheidet, welche Funktionen freigeschaltet werden, die Sitzplatzobergrenze, die Abrechnung pro Organisation und was passiert, wenn ein Abonnement ausläuft.

Eine Entität, zwei Stufen

Es gibt genau eine organizations -Entität. Ihre tier klassifiziert sie als Team oder Enterprise:

• Team Mitglieder, Rollen und Einladungen, native Gruppen, OAuth-Clients und ein Audit-Protokoll.
• Enterprise alles aus Team, plus eingehendes SSO (SAML-SP + OIDC-Föderation), SCIM-2.0-Bereitstellung und Verifizierung benutzerdefinierter Domains.

Die tier wird aus dem organisationseigenen Stripe-Abonnement abgeleitet — es gibt kein separates Plan-Flag, das synchron gehalten werden muss.

Ein Team erstellen (Self-Service)

Jeder angemeldete Benutzer kann ein Team erstellen mit POST /api/user/organizations — ohne Beteiligung eines Administrators. Neue Organisationen starten auf der Team-Stufe.

POST /api/user/organizations
Content-Type: application/json
Authorization: Bearer <user-session>

{
  "name": "Acme Inc"
}

# Response — you become the org owner
{
  "success": true,
  "data": { "id": "org_...", "name": "Acme Inc", "tier": "team" }
}

• Sie werden Eigentümer der von Ihnen erstellten Organisation.
• Jeder Benutzer darf höchstens 10 Organisationenbesitzen; die Erstellung ist atomar.
• Der Beitritt zu Organisationen anderer ist unbegrenzt — die Obergrenze gilt nur für eigene Organisationen.

Verwenden Sie in der Oberfläche die Schaltflächen „Team erstellen“ / „Verwalten“ in Ihren Organisationen in Ihrem Konto.

Der Organisationsadministrationsbereich

Eigentümer und Administratoren verwalten ihre Organisation über einen delegierten Administrationsbereich unter /org/[id]/admin/{users,groups,clients,domains,sso,billing,settings,policies,audit}. Jede Registerkarte ist organisationsbezogenen APIs zugeordnet.

• users · Mitglieder, Rollen und Einladungen
• groups · native Gruppen und Mitgliedschaft
• clients · OAuth-Clients im Besitz der Organisation
• domains · Verifizierung benutzerdefinierter Domains (Enterprise)
• sso · eingehende SAML- und OIDC-Föderation (Enterprise)
• billing · das Stripe-Abonnement und die Sitze pro Organisation
• settings · Organisationsprofil und Einstellungen
• policies · Zugriffs- und Sicherheitsrichtlinien
• audit · die Audit-Ereignisse der Organisation

Rollen und Isolation

Jede /api/org/[id]/* -Route prüft verifyOrgRole(role) vor jeder Aktion. Drei Rollen gelten:

• owner · volle Kontrolle, einschließlich Abrechnung und Löschung.
• admin · Mitglieder, Gruppen, Clients und Enterprise-Einstellungen verwalten.
• member · gehört der Organisation an, ohne Administratorrechte.

Organisationsrouten ERZWINGEN immer die org_id aus dem authentifizierten Prinzipal — niemals aus dem Anfragetext oder Pfad. Eine organisationsübergreifende Anfrage liefert 404, sodass eine Organisation niemals die Daten einer anderen lesen oder ändern kann.

Team vs. Enterprise — was eingeschränkt ist

Team deckt die tägliche Zusammenarbeit ab. Enterprise fügt die Identitätsföderations-Oberfläche hinzu. Die folgende Matrix zeigt, wo die Grenze verläuft:

Der Aufruf eines ausschließlich für Enterprise verfügbaren Endpunkts in einer Team-Organisation liefert HTTP 402 mit { "code": "upgrade_required" } — stufen Sie die Organisation hoch, um ihn freizuschalten.

# Calling an Enterprise-only endpoint on a Team org
POST /api/org/<orgId>/saml-idps
→ 402 Payment Required
{
  "success": false,
  "code": "upgrade_required"
}

Die Obergrenze von 25 Mitgliedern

Eine Organisation der Team-Stufe ist auf 25 Mitgliederbegrenzt. Das Limit wird sowohl beim Versenden einer Einladung als auch bei deren Annahme durchgesetzt, sodass eine ausstehende Einladung eine Organisation niemals über die Obergrenze bringen kann.

Das Überschreiten der Obergrenze liefert HTTP 402 mit { "code": "member_limit_reached" }. Erhöhen Sie das Limit durch ein Upgrade auf Enterprise.

# 26th member, either at invite OR at accept
POST /api/org/<orgId>/invitations
→ 402 Payment Required
{
  "success": false,
  "code": "member_limit_reached"
}

Abrechnung pro Organisation

Die Abrechnung ist an die Organisation gebunden, nicht an den Benutzer, der sie erstellt hat.

• Jede Organisation ist ihr eigener Stripe-Kunde.
• Abonnements werden pro Sitz abgerechnet.
• Ein Eigentümer kann separate Abonnements für mehrere Organisationen halten, die jeweils unabhängig in Rechnung gestellt werden.

Eigentümer verwalten das Abonnement, die Sitze und die Rechnungen unter /org/[id]/admin/billing.

Was bei einem Downgrade passiert

Enterprise-Funktionen folgen dem Abonnementstatus, aber ein Auslaufen sperrt Mitglieder niemals aus.

• Kündigung: ein echtes Abonnementende ( canceled/unpaid) deaktiviert die SSO-Identitätsanbieter der Organisation und widerruft ihre SCIM-Tokens.
• Überfällig: ein Stripe-Status past_due behält die Enterprise-Stufe während der Mahnfrist bei — es wird noch nichts deaktiviert.
• Erneutes Abonnieren: stellt die Stufe wieder her und reaktiviert automatisch die Identitätsanbieter, die bei der Kündigung automatisch deaktiviert wurden.

Enterprise-Konten

Eine Organisation der Enterprise-Stufe kann andere Organisationen besitzen — eine Organisation von Organisationen, ähnlich wie ein GitHub-Enterprise-Konto über vielen Orgs steht. Die Verknüpfung ist ein einzelner Elternverweis, und die Verschachtelung geht nur eine Ebene tief.

• Erstellen Sie untergeordnete Orgs aus dem Enterprise — nur für Inhaber und immer eine brandneue Org (bestehende Organisationen werden nie übernommen): POST /api/org/[id]/children
• Ein Enterprise-Inhaber oder -Administrator verwaltet automatisch jede untergeordnete Org, sodass dieselben /org/[id]/admin-Werkzeuge für alle funktionieren — ohne jeder einzeln hinzugefügt zu werden.
• Untergeordnete Orgs erben die Funktionen des Enterprise (SSO, SCIM, verifizierte Domains) und unbegrenzte Sitze; es gibt kein separates Abonnement pro untergeordneter Org.

Apps können auch den OIDC-Scope org anfordern, um die Rolle des Benutzers in der anfragenden Organisation zu erhalten (id, slug, name, role), pro Client aufgelöst wie der groups-Claim.