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

# Workspace

> The tenant boundary: how workspace_id is resolved, where to read it, and which operations accept or require it.

The workspace is the tenant boundary. Every authenticated operation resolves a
workspace from your credential and enforces it server-side — you cannot select
another tenant by sending a different `workspace_id`. Start with
`GET /api/v1/me` to see the workspaces your credential can reach and the
default workspace. Most requests can then omit `workspace_id`.

## Wire shape

A workspace entry returned by `GET /api/v1/me`:

| Field        | Type         | Meaning                                                 |
| ------------ | ------------ | ------------------------------------------------------- |
| `id`         | UUID         | The `workspace_id` used by workspace-scoped operations. |
| `name`       | string       | Display name.                                           |
| `is_default` | boolean      | Whether this is the credential's default workspace.     |
| `created_at` | ISO datetime | Creation time.                                          |

The `/me` response also includes `data.default_workspace_id` and the
credential's capabilities. It never returns key material.

## All operations on this resource

| Operation           | Method + path    | Auth    | Notes                                                                          |
| ------------------- | ---------------- | ------- | ------------------------------------------------------------------------------ |
| Describe credential | `GET /api/v1/me` | API key | Returns reachable workspaces, the default workspace, limits, and capabilities. |
| Manage workspace    | OrgX Settings    | Session | Create, rename, and delete workspaces in the app.                              |

```bash theme={"dark"}
curl https://useorgx.com/api/v1/me \
  -H "Authorization: Bearer $ORGX_API_KEY"
```

## Where the IDs come from

| Field          | Obtain it from                                                                                                       |
| -------------- | -------------------------------------------------------------------------------------------------------------------- |
| `workspace_id` | `GET /api/v1/me` → `data.default_workspace_id` or `data.workspaces[].id` — or omit it when the operation resolves it |
| `owner_id`     | Implicit in your API key; you never need to look it up for workspace-scoped calls                                    |

Operations that require an explicit `workspace_id` in the body or query:
`POST /api/v1/operating-processes` (and its transitions),
`POST /api/v1/handoffs` (and its transitions), `POST /api/v1/discovery-runs`,
`GET /api/v1/events/stream`, `GET /api/v1/projections/*`,
`GET /api/v1/episodes`, and `GET`/`POST /api/v1/decisions`. Work-item and
initiative operations resolve it automatically.

## MCP equivalents

`orgx_bootstrap` resolves the current workspace for a session. Workspace
creation and management remain signed-in app actions.