> For clean Markdown of any page, append `.md` to the page URL.
> For a complete documentation index, see https://docs.sarvam.ai/llms.txt.
> For full documentation content in one file, see https://docs.sarvam.ai/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.sarvam.ai/_mcp/server.

# Organisations & workspaces

> How Sarvam accounts are structured. An organisation is your billing and identity boundary; workspaces sit inside it and hold your API keys. Learn what lives where, the Owner and Member roles, and account limits.

Every Sarvam account has two levels: an **organisation** and one or more **workspaces** inside it.

#### Organisation

Your company. This is the billing and identity boundary, credits, invoices, plan, members, and account-level settings all live here.

#### Workspace

A space inside the organisation for a project, a team, or an environment. API keys are created and used inside a workspace, and usage is attributed to it.

When you sign up we create one organisation and one default workspace for you automatically, so you can start calling the APIs straight away.

## How we recommend you use them

**Create multiple workspaces, not multiple organisations.**

Keep one organisation for your company and add a workspace for each project, team, or environment. That way:

* everything is billed together out of one credit balance, so you don't have to top up in several places
* you can still see usage broken out per workspace
* you can give different people access to different projects

Create a second organisation only when you genuinely need a separate billing entity, for example a different legal entity, or a completely separate customer account you manage on someone else's behalf. Separate organisations mean separate credit balances, separate invoices, and separate member lists, with nothing shared between them.

> **Tip**
>
> The dialog under **Add Workspace or Organisation** spells out this same trade-off at the point of decision: a workspace "stays on the same bill", an organisation is "a separate billing entity with its own plan, invoices, and members".

## What lives where

### Organisation level

| Area             | What it covers                                                                         |
| ---------------- | -------------------------------------------------------------------------------------- |
| Billing          | Payment method, payment history, auto-recharge                                         |
| Credits          | One shared credit balance used by every workspace and every API key                    |
| Plans & pricing  | Your plan and negotiated rates                                                         |
| Usage            | Account-wide usage and spend                                                           |
| Members          | Everyone who can access the account, and their organisation role                       |
| General settings | Organisation name, logo, organisation ID, session idle timeout, model-training consent |

There is **one credit balance per organisation**. Every workspace and every API key draws from it, across every Sarvam product. There are no separate per-workspace balances or budgets.

### Workspace level

| Area              | What it covers                                                       |
| ----------------- | -------------------------------------------------------------------- |
| API keys          | Created inside a workspace and used by your application              |
| Usage attribution | Calls are attributed to the workspace they came from                 |
| Members           | Who from your organisation can access this workspace, and their role |
| Products          | Which Sarvam products this workspace uses                            |
| Data retention    | How long the workspace's data is kept, with per-product overrides    |
| General settings  | Workspace name, workspace ID, default-workspace flag                 |

> **Note**
>
> There is no billing at workspace level. If you are looking for credits, payment, or invoices, switch the settings scope to **Organisation**.

## Roles

Sarvam has two role systems: one at the organisation level and one per workspace.

### Organisation roles

#### Owner

Full control of the organisation. Owners can:

* rename the organisation, change its logo, and edit security settings
* invite, edit, and remove members, and change member roles
* create workspaces and manage workspace membership

Owners are automatically **Admin** on every workspace in the organisation, without needing an explicit grant.

#### Member

Can use the workspaces they have been given access to. Members cannot invite people, create workspaces, rename the organisation, or change anyone's role, those actions are rejected by the API, not merely hidden in the UI.

Members can see the organisation's member list, plan, and usage.

An organisation must always have **at least one Owner**. The last remaining Owner cannot be demoted or removed.

### Workspace roles

Set per workspace, and independent of the organisation role.

| Role       | What it allows                        |
| ---------- | ------------------------------------- |
| **Admin**  | Manages the workspace and its members |
| **Editor** | Works in the workspace                |
| **Viewer** | Read-only access                      |

## Limits

| Limit                            | Value               |
| -------------------------------- | ------------------- |
| Workspaces per organisation      | 100                 |
| Organisations you can own        | 100                 |
| Workspaces per single invite     | 50                  |
| Active API keys per organisation | 50                  |
| Members per organisation         | No limit            |
| Owners per organisation          | At least 1 required |

> **Note**
>
> If you need more than 50 active API keys, [contact the team](mailto:support@sarvam.ai), the cap is not self-serve.

## Common setups

#### Solo developer or small team

One organisation, the default workspace. Add a second workspace when you want to separate production traffic from your own testing.

#### Company with several products

One organisation, one workspace per product. Billing stays in one place; usage per product is visible separately.

#### Company with dev / staging / prod

One organisation, three workspaces, separate API keys in each. Rotating or revoking a staging key never touches production.

#### Agency or consultancy building for clients

One workspace per client if you're paying for it and want a single bill. A separate organisation per client only if each client needs to be invoiced directly.

## Next steps

#### [Create an organisation](/api/platform/create-an-organisation)

Set up a separate billing entity.

#### [Create a workspace](/api/platform/create-a-workspace)

Add a project or environment inside your organisation.

#### [Invite your team](/api/platform/invite-your-team)

Add people and give them workspace access.

#### [Billing & payments](/api/platform/billing)

Credits, adding funds, and auto-recharge.

#### [Data retention](/api/platform/data-retention)

Set how long your workspace's data is kept, with per-product overrides.

> How Sarvam accounts are structured. An organisation is your billing and identity boundary; workspaces sit inside it and hold your API keys. Learn what lives where, the Owner and Member roles, and account limits.