Organisationen

Eine Organisation ist der oberste Container in fastmon. Sites, Mitglieder, Einladungen, Notification Rules: alles hängt an genau einer Organisation, und nichts geht darüber hinaus.

Warum das wichtig ist

Über die Organisation trennt fastmon Kunden voneinander. Hier hängen Billing, Plan und Zugriffsrechte.

Die meisten Accounts haben genau eine Organisation. Mehrere lohnen sich vor allem für Agenturen und Partner; siehe partner-Plan unten.

Wann du sie anfasst

• Beim Setup. Das Allererste. Der „Account anlegen"-Flow legt eine Organisation für dich an.
• Team einladen. Per E-Mail, Rolle zuweisen, fertig.
• Plan kaufen. Plan hängt an der Organisation, nicht am User.
• AVV oder Rechnung anfordern. Die Organisation ist die Vertragspartei.
• Compliance-Review. „Wer hat Zugriff?" beantwortet sich auf Organisations-Ebene.

Was eine Organisation hat

Pläne

Eine neue Organisation startet auf none und verlässt diesen Zustand über genau drei Wege: eine Freigabe startet ihre Testphase, ein Checkout kauft einen Plan, oder ein Partner richtet sie ein.

Der Plan steuert Features und Quotas. Welche Web Vitals erfasst werden, hängt nicht am Plan; gemessen wird in jedem Plan dasselbe.

Worin ein Plan gemessen wird. Abgerechnet wird die Application, und nur eine Production-Application belegt einen Platz: eine Development-Application ist kostenlos und unbegrenzt. Ein Plan enthält eine Anzahl Production-Plätze und ein monatliches Pageview-Volumen; beides lässt sich über dauerhafte Add-ons erweitern, die im Voraus gekauft werden und nicht nach einem Ausschlag abgerechnet. Eine Production-Application über die enthaltenen Plätze hinaus anzulegen oder hochzustufen wird mit 402 app_limit_reached abgewiesen (siehe Fehler); eine Organisation ohne jede Berechtigung bekommt 402 billing_required oder 402 trial_expired.

Rollen

Eine Rolle ist ein festes Bündel von Berechtigungen. Eine Berechtigung ist eine einzelne Fähigkeit in der Form resource:action (analytics:read, release:write, member:manage); jede API-Route nennt die, die sie braucht, und das Dashboard blendet Aktionen nach derselben Liste ein oder aus. GET /permissions listet jede Berechtigung mit Beschreibung und den Rollen, die sie haben.

Billing sind zwei Berechtigungen, nicht eine Rolle. billing:read öffnet die Rechnungen, die Rechnungsadresse und die USt-IdNr.; billing:manage bewegt das Geld. Lesen ist eine Member-Berechtigung und bewusst außerhalb des Viewer-Bündels: ein Nur-Lese-Platz sieht den Billing-Tab also gar nicht, statt ihn auf eine Reihe von 403ern zu öffnen. Bezahlen bleibt beim Owner. Eine Agentur, die die Rechnungen ihres Kunden liest, ist dort Member, und das ist genau billing:read ohne billing:manage.

Die Bündel sind ineinander geschachtelt: Ein Mitglied hat alles, was ein Viewer hat, ein Owner alles, was ein Mitglied hat. Persönliche API-Keys werden aus denselben Bündeln geschnitten: Die Scopes eines Keys sind Berechtigungen, bei jedem Request mit deiner aktuellen Rolle geschnitten. Ein Organisations-Key gehört stattdessen der Organisation und steht allein auf seinen Scopes, begrenzt beim Ausstellen. Organisations-Keys und verbundene Apps verwaltet, wer org_key:manage hält: Member und Owner, nicht Viewer.

Eine Organisation kann mehrere Owner haben. Owner ändern Rollen unter Mitglieder (PATCH /members/{member_id}); nur ein Owner kann die Owner-Rolle vergeben. Der letzte Owner kann weder herabgestuft werden noch die Organisation verlassen, solange andere Mitglieder da sind (last_owner). Transfer ownership übergibt die Organisation in einem Schritt an ein anderes Mitglied.

Häufige Szenarien

Ein Produkt, eine Org

Der Standardfall. Eine Organisation, eine Rechnung, mehrere Sites darunter (acme-marketing, acme-app, acme-docs).

Mehrere unabhängige Produkte

Wenn du zwei eigenständige Brands betreibst und Billing wie Zugriffe sauber trennen willst, leg zwei Organisationen an. Du kannst in beiden Mitglied sein.

Agentur, die Kunden-Sites betreibt

Hier passt der partner-Plan. Jeder Kunde ist ein Partner-Client: eine Sub-Organisation, die die Agentur verwaltet. Agentur-User sehen alle Clients, der Kunde nur sich selbst. Eine Partner-Organisation kann außerdem einen API-Key ausstellen, der ihrer Client-Liste folgt, statt eines Keys pro Client.

Jedes Mitglied der Partner-Organisation kann einen Client anlegen, ihn per owner_email an den Kunden übergeben und ihn wieder ablösen; umgekehrt kann ein Mitglied der Kunden-Organisation den Zugriff der Agentur entziehen. Diese Routen schützt die direkte Mitgliedschaft: eine Agentur, die eine Organisation über eine Partnerschaft erreicht, kann dort weder deren eigene Clients verwalten noch eine Partner-Verbindung entziehen.

Häufige Überraschungen

• Der Org-Switcher ist nur ein UI-Knopf. API-Requests scopen über die URL (/organizations/{id}/…), nicht über irgendeinen aktiven Tab.
• Mitglieder sind globale fastmon-User. Lädst du einen bestehenden User neu ein, wird der bestehende Account weiterverwendet, kein Duplikat.
• Ein Mitglied direkt hinzufügen darf nur ein Owner. POST /organizations/{id}/members braucht member:manage. Mitglieder laden stattdessen ein, und die Einladung trägt die Rolle.
• Sites können nicht zwischen Organisationen umziehen. Falls doch nötig: Support melden, das geht nicht per Self-Service.

Verwandt

• Sites: die Ressourcen, die einer Organisation gehören.
• API: Organizations-Endpunkte: programmatischer Zugriff.