Organisationen
Das Konto deiner Firma oder deines Teams, mit Plan, Abrechnung und Mitgliedern.
Eine Organisation ist das Konto deiner Firma oder deines Teams in fastmon. Sie hat den Plan, die Abrechnung und die Mitglieder. Jede Site, Einladung und Notification Rule gehört zu genau einer Organisation.
Was eine Organisation hat
| Feld | Typ | Hinweise |
|---|---|---|
id | UUID v7 | Stabiler Identifier. Verwendet in API-URLs (/organizations/{id}/…). |
name | string | Menschenlesbar. Erscheint im Org-Switcher. |
plan | enum | none, free, one, partner oder enterprise. |
members | Liste von { user_id, role } | Rollen: owner, member, viewer. Die Antwort trägt außerdem deine eigene role und deine permissions. |
Pläne
| Plan | Wann passt er |
|---|---|
none | Der Startzustand. Es hat noch niemand etwas gewählt. |
free | fastmon One ohne Bezahlung: alle Features, unbegrenzte Pageviews und Applications. |
one | Der einzige buchbare Plan, verkauft als fastmon One. Alles enthalten. |
partner | Agenturen. Partner-Clients verwalten (Sub-Organisationen, die die Agentur für jemand anderen betreibt). |
enterprise | fastmon Enterprise. Custom-Limits, Custom-Retention, AVV. |
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, nicht die Metriken. features nennt jedes Feature mit Status: covered durch einen Partner, granted von fastmon, included im Plan oder locked.
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 mit dauerhaften Add-ons im Voraus erweitern. 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.
Das Pageview-Volumen zählt jeden gespeicherten Pageview einmal, Bots eingeschlossen. Ein gesampelter Pageview zählt so, wie er gespeichert ist, nicht hochgerechnet, und die letzten 15 Minuten zählen, sobald sie finalisiert sind. GET /organizations/{id}/usage liefert es als pageview_count mit seinem time_range.
E-Rechnungen. Geschäftskunden in Deutschland, den Niederlanden und Belgien mit USt-IdNr. bekommen jede Rechnung zusätzlich über Peppol. Die USt-IdNr. ist die Peppol-Kennung und muss zu deiner Registrierung passen.
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.
| Rolle | Darf |
|---|---|
owner | Alles, was ein Mitglied darf, und dazu: Organisationseinstellungen (Name, Einwilligung zu KI und Synthetic Monitoring), Mitglieder und ihre Rollen, Notification Rules, Audit-Log, Bezahlen (billing:manage), Übergabe und Löschung. |
member | Die tägliche Arbeit: Sites, Applications, Releases und Synthetic-Seiten anlegen und ändern; Synthetic-Runs starten; den KI-Assistenten fragen; Leute einladen; die Rechnungen lesen (billing:read); in einer partner-Organisation deren Clients verwalten (partner:manage). |
viewer | Nur lesen. Sieht Dashboards, Analytics, Releases, Synthetic-Ergebnisse, Notification Rules und die Mitgliederliste. Ändert nichts, löst nichts aus, was Geld kostet oder Mails verschickt, und sieht kein Billing. |
Billing sind zwei Berechtigungen, nicht eine Rolle. billing:read öffnet die Rechnungen, die Rechnungsadresse und die USt-IdNr.; billing:manage bewegt das Geld.
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.
Partner-Zugriff
In einer Client-Organisation hat ein Partner-Mitarbeiter dieselbe Rolle wie in der Partner-Organisation: owner, member oder viewer. Betreuen zwei Agenturen denselben Client, gilt die stärkere Rolle. Eine direkte Mitgliedschaft im Client geht vor.
Über Partner-Zugriff kannst du im Client Organisations-Keys ausstellen und Apps der Organisation verbinden, etwa das Shopware-Plugin per OAuth. Auch als Owner der Agentur kannst du im Client Folgendes nicht:
- Ihn löschen, sein letztes Mitglied entfernen, ihn übergeben oder sein Billing verwalten.
- Seine Owner herabstufen oder entfernen, oder die Owner-Rolle vergeben, solange er einen Owner hat.
- Mitglieder ohne Einladung hinzufügen oder seine Partner-Verbindungen verwalten.
- Keys für die eigenen Clients des Clients ausstellen.
Vom Partner erstellte Zugänge überleben die Partnerschaft. Key- und Verbindungsliste des Clients markieren sie mit via_partner_org_id, und beim Ablösen eines Partners werden sie aufgelistet.
Der Client rotiert die Keys und trennt die Apps. Rotiert ein Mitglied des Clients, entfällt die Markierung.
Der Audit-Eintrag partner.removed nennt sie in credentials_left. Er erscheint im Audit-Log beider Organisationen.
Häufige Szenarien
Ein Produkt, eine Org
Eine Organisation, eine Rechnung, mehrere Sites darunter (acme-marketing, acme-app, acme-docs).
Mehrere unabhängige Produkte
Für zwei eigenständige Brands mit getrenntem Billing und Zugriff legst du 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.
Ein Partner deckt Features und Pageviews pro Client mit PATCH /organizations/{org_id}/partner/clients/{client_org_id} ab, im Rahmen von GET /organizations/{org_id}/partner/contract.
Ein Mitglied der Partner-Organisation legt einen Client an, übergibt ihn per owner_email und löst ihn wieder ab. Ein Mitglied des Clients entzieht der Agentur den Zugriff. Beides braucht direkte Mitgliedschaft, siehe Partner-Zugriff.
Der Partnerfloor zeigt den Live-Traffic aller Clients.
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 ein, bekommt er keinen zweiten Account.
- Eine Einladung wartet am Konto. Wer sich ohne den Link aus der Mail registriert hat, findet seine offenen Einladungen auf dem Startbildschirm.
- Ein Mitglied direkt hinzufügen darf nur ein Owner.
POST /organizations/{id}/membersbrauchtmember:manage. Mitglieder laden stattdessen ein, und die Einladung trägt die Rolle. - Sites können nicht zwischen Organisationen umziehen. Wenn du das brauchst, melde dich beim Support.
Verwandt
- Sites: die Ressourcen, die einer Organisation gehören.
- API: Organizations-Endpunkte: programmatischer Zugriff.