Mandantenmodell — Zwei unterstützte Formen
Audact unterstützt sowohl die öffentliche schlüssellose als auch die org-eigene Mandanten-Bereitstellung. Wählen Sie die Form, die zu Ihrer Integration passt.
Audact unterstützt beide Formen der Mandanten-Bereitstellung, zwischen denen ein Integrator wählen kann — dies ist eine Designentscheidung auf Seite des Aufrufers, keine Lücke in der API.
Form 1 — Öffentliche, schlüssellose Mandantenerstellung
POST /v1/tenants (Mandantenverwaltung, nicht authentifiziert)
- Kein API-Schlüssel oder Org-Konto erforderlich, um diesen Endpunkt aufzurufen.
- IP-Rate-limitiert auf 5 Erstellungen pro IP pro Stunde, da er andernfalls offen ist.
- Mandanten-Lebenszyklus ab hier:
GET /v1/tenants/{tenant_id}(Viewer+),PUT /v1/tenants/{tenant_id}(Owner), API-Schlüssel überPOST/GET/DELETE /v1/tenants/{tenant_id}/keys[/{key_id}](Owner zum Erstellen/ Widerrufen, Developer+ zum Auflisten).
Form 2 — Org-eigene Mandanten mit vollständigem Lebenszyklus
POST /v1/org/tenants (Org-Verwaltung, erfordert eine authentifizierte, verifizierte
Organisation) — erstellt einen Mandanten, der der Organisation des Aufrufers gehört,
bewusst ohne API-Schlüssel oder Standardkonfiguration; diese werden in einem
separaten initialize-Schritt nachgereicht, sodass Mandantenerstellung und
Mandantenaktivierung zwei auditierbare Aktionen sind.
Vollständiger Lebenszyklus im org-eigenen Modell:
| Endpunkt | Wirkung |
|---|---|
POST /v1/org/tenants | Erstellt die Mandantenzeile, die der Org gehört. Noch kein Schlüssel, keine Konfiguration. |
POST /v1/org/tenants/{id}/initialize | Initialisiert die erste versiegelte Standardkonfiguration des Mandanten und gibt den ersten Owner-API-Schlüssel zurück (idempotent — antwortet bei einem zweiten Aufruf mit 409 already_initialized, statt einen Duplikateintrag zu erstellen). |
POST /v1/org/tenants/{id}/keys | Erstellt einen zusätzlichen Owner-API-Schlüssel ohne Änderung der Konfiguration. |
POST /v1/org/tenants/{id}/enable | Setzt status=active, löscht den org:tenant-disabled-Redis-Marker. |
POST /v1/org/tenants/{id}/disable | Dies ist PAUSE — siehe unten. |
DELETE /v1/org/tenants/{id} | Logisches Löschen: setzt deleted_at, setzt den org:tenant-disabled-Marker. Der KMS-HMAC-Schlüssel des Mandanten bleibt erhalten und wird nie entzogen. |
POST /v1/org/tenants/{id}/restore | Löscht deleted_at bei einem soft-gelöschten Mandanten; verwendet den ursprünglichen hmac_key_arn unverändert (keine Neu-Bereitstellung, kein neuer Schlüssel/keine neue Konfiguration). |
POST /v1/org/tenants/{id}/impersonate | Erstellt ein kurzlebiges (~20 Min.) mandantengebundenes JWT, damit der Org-Admin als Owner des Mandanten gegenüber mandantenorientierten Diensten handeln kann; jeder Aufruf wird im Audit-Log erfasst. |
disable ist eine echte PAUSE
POST /v1/org/tenants/{id}/disable versetzt den Mandanten in status=disabled und
setzt den org:tenant-disabled:{tenant_id}-Redis-Marker. Ab diesem Zeitpunkt:
- Die API-Schlüssel-Authentifizierungs-Middleware prüft diesen Marker auf dem Hot Path
und lehnt jede Anfrage, die mit den API-Schlüsseln dieses Mandanten authentifiziert
ist, mit
403, Fehlercodetenant_disabledab — einschließlich per Impersonation erstellter Token. - Die Prüfung schlägt offen fehl (lässt die Anfrage durch und protokolliert eine Warnung), wenn Redis selbst nicht erreichbar ist, damit ein Redis-Ausfall nicht selbst zu einem Verfügbarkeitsvorfall für Mandanten führt, die nicht deaktiviert sind.
enablelöscht den Marker und stelltstatus=activewieder her; die Umkehrung erfolgt sofort.
Dies ist das mandantengranulare Äquivalent einer PAUSE. DID-Level-Pause — das Halten einer Telefonnummer ohne Routing — ist ein separates Konzept.
Pro-Mandant-Isolation in beiden Formen
- API-Schlüssel und das Webhook-HMAC-Signing-Secret sind pro Mandant, unabhängig davon, welche Form den Mandanten erstellt hat — es gibt kein gemeinsames/globales Signing-Secret.
- Jede Abfrage in der Mandanten-/Org-Verwaltung schränkt nach
tenant_idaus dem authentifizierten Kontext ein, nie aus einem Anfrage-Body-Feld.
Empfehlung
Ein Audact-Mandant pro integratorseitigem Mandanten bietet Ihnen pro-Mandant-Isolation
von API-Schlüssel/Secret, die disable → PAUSE-Zuordnung genau auf der Granularitätsebene,
die Sie wahrscheinlich benötigen, sowie die bestehende mandantenübergreifende
Isolationsgrenze von Audact — kostenlos, ohne zusätzliche Infrastruktur. Die API erzwingt
diese Zuordnung nicht, aber sie ist die am einfachsten nachzuvollziehende.