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

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                            |
| General settings  | Workspace name, workspace ID, default-workspace flag                 |

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 |

If you need more than 50 active API keys, [contact the team](mailto:developer@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.