> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Manager accounts > Operate many client organizations from one credential — provision an org per customer and run them all with a single manager key, instead of a pasted key per tenant. # Manager accounts A **manager account** lets one organization operate many client ("managed") organizations with a **single credential**. It's the pattern a portal uses to run an Erdo org per customer: instead of minting and pasting a separate API key for every tenant, you provision each client org under your manager org and operate them all with one **manager key**. This mirrors how a Google Ads MCC (manager account) operates many ad accounts, and how a SaaS control plane runs a tenant per customer. If you're building a product on top of Erdo that gives each of your customers their own isolated org, this is the surface you want. ## How it works Your **active org is the manager** — you must be an admin or owner of it. Two things hang off it: * **Managed orgs** — the client tenants you provision. Each is a full, isolated Erdo organization: its own datasets, pages, knowledge, and RBAC. Creating one records a management link (kept as an audit trail even after you stop managing) and its own identity inside the org, so downstream setup seeds with a real owner. * **The manager key** — one non-expiring API key, held by your manager org, that is a member of every org you manage. You operate a specific managed org by naming it in the request: pass its slug or id as the `X-Organization-ID` header (or `erdo --org ` on the CLI). The backend re-validates the manager's membership in that org on every request, so revoking management ends access immediately. Because access is enforced by membership plus the org header — the same mechanics as any Erdo token — there is no new auth path to reason about. A managed org's service usage never counts toward your manager org's billable seats, and never appears in its Team list. ## Provisioning a client org from a portal The typical portal flow, once per customer: Call `create managed organization` with the customer's name. You get back the new org's **slug** — the durable handle you store against that customer. Call `create manager key` to mint the single credential your portal holds. It's returned exactly once; store it as a secret. You only do this once (or again to rotate). Send the manager key with `X-Organization-ID` set to the customer's org slug to do anything inside that org — create datasets, build pages, run agents. The same key operates every customer. Call `revoke managed organization` with the slug to end management. Access stops immediately; the management link is retained as an audit record. Only an admin/owner of the manager org can create, revoke, or mint the key — the same authority check on every surface below. Listing is available to any member of the manager org. ## Erdo platform Open **Settings → Manager Accounts** in the Erdo platform to create and view client organisations, stop managing an organisation, or create and rotate the manager key. The raw key is shown once: copy it into your server-side secret manager before leaving the page. This surface is available to ordinary Erdo organisations; creating, revoking, and rotating require an admin or owner. ## CLI ```bash theme={null} # provision a client org (prints its slug) erdo org managed create --name "Acme Corp" # list the orgs you manage — slug name role id erdo org managed list # mint (or rotate) the one manager key — shown ONCE erdo org managed key # operate a managed org with that key erdo --org acme-corp-a1b2c3d4 datasets list erdo --org acme-corp-a1b2c3d4 pages list # stop managing a client org (keeps an audit record) erdo org managed revoke acme-corp-a1b2c3d4 ``` The CLI authenticates with your Erdo token and active org (`erdo login`, `erdo org use`). In CI, set the manager key as `ERDO_API_KEY` and pin the target tenant with `ERDO_ORG` or `--org`. See the [CLI reference](/cli#manager-accounts). ## MCP tools | Tool | What it does | | ---------------------------------- | ---------------------------------------------------------------------------------- | | `erdo_list_managed_organizations` | List the client orgs your org manages — slug, name, management role, created time. | | `erdo_create_managed_organization` | Provision a new client org under your org (name, optional slug). Returns its slug. | | `erdo_revoke_managed_organization` | Stop managing a client org, named by slug. Idempotent; keeps the audit link. | Identity and RBAC ride the request context — a caller only ever acts as their own manager org, and managed orgs are referenced by **slug**, never a UUID. Manager keys are deliberately not minted by an MCP tool: a model-facing tool must not create a non-expiring credential. Create or rotate the key from Platform, the CLI, or `POST /v1/manager-key`, then use that credential to operate managed orgs through MCP. ## REST Base URL `https://api.erdo.ai`. Authenticate with `Authorization: Bearer ` and select the manager org with `X-Organization-ID` (for the lifecycle calls, that's your manager org; to operate a managed org, set it to that org's slug/id). | Method | Path | Purpose | | -------- | --------------------------------- | ---------------------------------------------------------- | | `GET` | `/v1/managed-organizations` | List the orgs you manage. | | `POST` | `/v1/managed-organizations` | Create a managed org (`{ "name": "...", "slug": "..." }`). | | `DELETE` | `/v1/managed-organizations/:slug` | Stop managing the org (idempotent). | | `POST` | `/v1/manager-key` | Mint/rotate the manager key. The raw key is returned once. | The manager key returned by `POST /v1/manager-key` is a standard `erdo_api_*` bearer token pinned to your manager org — send it as `Authorization: Bearer ` with `X-Organization-ID: ` to act inside any org you manage.