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

# Mission workspaces

> Keep Mission Analysis and Operations work separate within one organization.

<Info>
  Named workspace management is released by organization/account eligibility.
  If it is not available to you, your existing MA and OPS working contexts remain
  available with their original data and access.
</Info>

## Select a workspace

Use the existing workspace selector in the application header. Named workspaces
show their **name and type**: Mission Analysis or Operations. You only see
workspaces you are authorized to open. Switching opens that workspace's retained
mission data and results; it does not move previously started calculations.

Your choice is remembered separately for each organization and type. On the
first entry into a type, its default workspace is targeted. A workspace link can
carry `?workspace=<workspace-id>` to select a specific workspace. If a remembered
or linked workspace is unavailable, the application shows that access outcome
and lets you choose another authorized workspace explicitly. It does not silently
substitute a different workspace.

## Manage workspaces

Organization administrators with access to this capability use **Settings →
Organization → Workspaces** to create, rename, archive, restore and manage members.

* Create a named workspace of an enabled type. It starts empty with no members;
  assign organization members explicitly afterward.
* Rename without changing the workspace ID, mission data, membership or
  integration targets. `default` is an initial name, not a reserved name.
* Archive only after running jobs finish and enabled operational schedules are
  disabled. Connected or leased operational integrations also identify work that
  must be resolved through their existing controls. The rejection identifies blockers.
* Open archived contents read-only under your existing permissions.
* Restore retained contents and membership. Disabled schedules and disconnected
  integrations are not enabled automatically.

Each organization/type has a permanent default identity. Renaming or archiving
that workspace does not appoint a replacement default.

## Target the customer API

An existing integration that omits a workspace continues to target the permanent
default for its MA/OPS type. A browser's selection does not change that target.

To select another authorized workspace, supply the UUID in `X-Workspace-Id`:

```http theme={null}
GET /operations/spacecraft HTTP/1.1
Authorization: Bearer <access-token>
X-Workspace-Id: <workspace-uuid>
```

The header does not grant access. A wrong type, another organization, invalid ID
or inaccessible workspace is rejected. API keys retain their own environment
grant and need an explicit workspace grant for additional workspaces.

The TypeScript SDK retains its existing method parameters. Supply the selector
through the existing request options instead of adding a positional argument:

```typescript theme={null}
await spacecraftApi.getSpacecraft({ id: spacecraftId }, {
  headers: { 'X-Workspace-Id': workspaceId },
});
```

If a default is archived, authorized implicit reads still read its retained
contents and writes are rejected. If default access is revoked, requests are
denied. Neither condition redirects the integration to another workspace.

### Workspace administration endpoints

These operations remain organization-admin authorized and release controlled:

| Operation | Endpoint |
| - | - |
| List your authorized workspaces | `GET /workspaces/me` |
| List the organization's workspace administration catalog | `GET /workspaces` |
| Create an empty workspace | `POST /workspaces` with `environment` and `name` |
| Rename | `PATCH /workspaces/{id}` with `name` |
| Archive or restore | `PATCH /workspaces/{id}/lifecycle` with `archived: true` or `false` |
| Read or replace membership | `GET` or `PUT /workspaces/{id}/members`; both use an object with `userIds` |
| Grant or revoke an API key | `PUT /workspaces/{id}/api-keys` with `apiKeyId` and `grant` |

Archive blockers return HTTP `409` in the standard error envelope; optional
`details.blockers` identifies the running jobs or enabled schedules to resolve.

Revoking a grant does not change the implicit default binding. Separate station
sharing, copying, permanent deletion and type conversion are not supported by
this workspace lifecycle.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.