Skip to main content
Ein Workspace ist ein vollständig isolierter Tenant: eigene Assistenten, Anrufe, Kampagnen, Knowledgebases, Telefonnummern, Plan, Guthaben und Abrechnung. Die Registrierung legt automatisch einen persönlichen Workspace an, in dem du Owner bist. Von dort aus kannst du in die Workspaces anderer eingeladen werden — als Member (oder Admin, Viewer, Billing) — und innerhalb deines Plan-Limits eigene weitere Workspaces anlegen.

​
Workspace wechseln

Klicke oben in der Sidebar auf den Workspace-Avatar, um den Switcher zu öffnen. Er listet jeden Workspace, dem du angehörst, mit deiner jeweiligen Rolle. Die Auswahl setzt den Workspace als aktiv und lädt die App neu, damit jede serverseitige Route ihn sofort berücksichtigt. Der aktive Workspace ändert sich nur für deine eigene Browser-Sitzung — nie für das, was andere Mitglieder eines Workspace sehen.

​
Weiteren Workspace anlegen

Öffne den Switcher und wähle New workspace im Footer, oder rufe direkt POST /api/workspaces auf. Du wirst Owner dieses Workspace; er startet mit eigenem (noch unkonfiguriertem) Plan und ohne Guthaben. Wie viele weitere Workspaces du anlegen darfst, ist ein Plan-Limit, max_workspaces:
  • -1 bedeutet unbegrenzt.
  • 0 (Standard) bedeutet, das Feature ist aus — du kannst weiterhin in Workspaces anderer eingeladen werden, nur eigene über den aus der Registrierung hinaus kannst du nicht anlegen.
  • Jede andere Zahl ist die Anzahl Workspaces, die du zusätzlich zu deinem ersten anlegen darfst — ein Plan mit max_workspaces: 2 erlaubt dir also insgesamt 3 Workspaces.
Dein Kontingent ist der höchste max_workspaces-Wert über alle Workspaces, die du bereits besitzt — ein Workspace auf einem höheren Plan erhöht dein Kontingent überall, auch für Workspaces, die du später auf einem niedrigeren Plan angelegt hast. Gehörst du Workspaces nur als Mitglied an (nie als Owner), ist dein Kontingent 0: Ein neu angelegter Workspace macht dich immer zu dessen Owner, das Kontingent richtet sich also nach einem Plan, den du besitzt, nicht nach einem, in den du nur eingeladen wurdest. Brauchst du mehr als dein Plan enthält? Das Add-on extra_workspaces (wo für deinen Plan aktiviert) erhöht dein Kontingent in gestaffelten Schritten, ohne deinen Basis-Plan zu ändern. Ein Plattform-Admin-Support-Override kann das Kontingent eines einzelnen Kontos außerdem direkt anheben oder senken. Das Anlegen eines Workspace ist auf jeweils eine Marke begrenzt: Auf der Hauptdomain der Plattform kannst du nur Plattform-Workspaces anlegen, auf der Domain eines White-Label-Resellers nur Workspaces, die zu diesem Reseller gehören. Bestehende Workspaces werden nie gesperrt oder ausgeblendet, wenn du später dein Kontingent erreichst oder überschreitest — das Limit blockiert ausschließlich das Anlegen neuer Workspaces.
Einen Workspace anzulegen setzt ein authentifiziertes, nicht gesperrtes Konto voraus. Es hängt nie von deiner Rolle im gerade aktiven Workspace ab — ein member in einem Workspace kann trotzdem einen komplett neuen anlegen und besitzen.

​
Teammitglieder einladen

Jeder Workspace verwaltet seine Mitgliedschaft unabhängig unter Einstellungen → Team, bezogen auf den gerade aktiven Workspace — der Panel-Header nennt ihn, sodass immer klar ist, in welchen Workspace eine Einladung geht. Rollen (owner, admin, member, viewer, billing) sind pro Workspace: Dieselbe Person kann in einem Workspace Owner sein und in einem anderen nur lesenden Viewer-Zugriff haben.

​
REST API

GET /api/v1/workspaces listet jeden Workspace, der für den aufrufenden Credential sichtbar ist: bei einem nutzergebundenen API-Key oder OAuth-Token jeden Workspace, dem dessen Owner innerhalb der eigenen Marke dieses Keys angehört, wobei der eigene Workspace des Keys current: true trägt. Ein Service-Account-Key ist naturgemäß ein einzelner Workspace und listet nur sich selbst. POST /api/v1/workspaces benötigt ein nutzergebundenes Credential — ein Service-Account-Key kann keinen Workspace besitzen und erhält 403. Bei Erfolg liefert die Antwort den neuen Workspace mit role: "owner". Ist das Kontingent ausgeschöpft, schlägt der Aufruf mit 403 { error: { code: "forbidden" }, meta: { used, allowed } } fehl. REST-Scopes sind settings:read / settings:write.

​
MCP

  • list_workspaces — dieselben Sichtbarkeitsregeln wie der REST-List-Endpoint.
  • create_workspace — dasselbe Kontingent und dieselbe Anforderung eines nutzergebundenen Credentials wie der REST-Create-Endpoint.
Alle MCP-Ergebnisse verwenden denselben Public-Payload-Sanitizer wie die REST API — die interne ID eines Workspace wird ausschließlich als id ausgegeben, nie als tenant_id.