Multi-Tenancy
Codemeta OS ist ein Multi-Tenant-SaaS. Jeder Mandant ist datentechnisch isoliert —
jeder Datensatz trägt einen tenantId-Bezug, jede API-Query filtert zwingend
nach Mandant.
Der Header X-Tenant-Id
Jeder Request gegen /api/v1/... braucht X-Tenant-Id. Fehlt er, antwortet die
API mit 400 Bad Request.
GET /api/v1/tickets HTTP/1.1
Host: os.codemeta.de
X-Tenant-Id: 0192f2c0-8d1c-7a3b-9e4f-d3e7f1a2b5c8
Cookie: codemeta-session=…
Der Wert ist die UUIDv7 des Mandanten. Welche Mandanten Ihrem Account zugeordnet sind, erfahren Sie über das User-Profile-Endpoint.
User-zu-Mandanten-Mapping
Ein Account kann mehreren Mandanten gleichzeitig angehören (typisch für Systemhaus-Mitarbeitende mit Customer-Tenant-Zugriff). Welche Mandanten Ihrem Account zur Verfügung stehen, sehen Sie nach dem Sign-in über das Tenants-Endpoint.
Mandantenfremder Zugriff
Manche Kontexte – etwa Cross-Tenant-Operations für MSP→Customer-Workflows –
brauchen Zugriff über mehrere Mandanten. Das geht nur über den expliziten
Query-Parameter ?crossTenant=true und ist über zusätzliche Permissions
abgesichert.
Was bedeutet das für Ihren Code?
- Cookie + Header pro Mandant cachen. Speichern Sie
cookies.txtund dietenantIdzusammen. Wenn Ihre Anwendung mit mehreren Mandanten arbeitet, laufen Requests pro Mandant in eigenen Sessions. - Niemals
tenantIdals Body-Feld setzen. Die API leitet sie ausschließlich aus dem Header ab. Ein Body-FeldtenantIdwird ignoriert oder abgelehnt. - Bei 403 nicht den Mandanten raten. Wenn ein GET 403 liefert, prüfen Sie zuerst die Datenscopes – nicht den Mandanten. Mehr dazu unter Berechtigungen & Scopes.