> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ouraicalling.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workspaces

> Zwischen Workspaces wechseln, weitere innerhalb des Plan-Limits anlegen und Teammitglieder in jeden einzelnen einladen.

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.

<Note>
  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.
</Note>

## 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

```bash theme={null}
curl https://YOUR_DOMAIN/api/v1/workspaces \
  -H "Authorization: Bearer fam_..."
```

```bash theme={null}
curl -X POST https://YOUR_DOMAIN/api/v1/workspaces \
  -H "Authorization: Bearer fam_..." \
  -H "Content-Type: application/json" \
  -d '{"name":"Acme Corp — EU"}'
```

`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`.