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

# Workspaces

> Planned workspace settings and administration categories for the Woes public API.

Workspace APIs will cover administrative objects that shape how a team uses Woes. These APIs should be treated as privileged because they can affect access, routing, customer-facing behavior, and support operations.

## Planned resources

| Resource              | Purpose                                                          |
| --------------------- | ---------------------------------------------------------------- |
| Workspace profile     | Company identity and workspace metadata.                         |
| Members               | People with access to the workspace.                             |
| Roles and permissions | Access boundaries for settings, inbox, automations, and context. |
| Tags                  | Managed labels for conversations, issues, and accounts.          |
| Custom fields         | Structured context fields for customers and conversations.       |
| Macros                | Reusable replies and workflow actions.                           |
| Automations           | Rules that tag, route, delay, or annotate support work.          |
| Channel settings      | Workspace-level channel configuration.                           |

## Common use cases

<CardGroup cols={2}>
  <Card title="Sync team membership" icon="users">
    Keep support access aligned with another internal system.
  </Card>

  <Card title="Mirror CRM fields" icon="database">
    Align tags or custom fields with your source of truth.
  </Card>

  <Card title="Manage support content" icon="message-square-quote">
    Keep macros and labels aligned with product documentation.
  </Card>

  <Card title="Build admin tooling" icon="wrench">
    Create internal dashboards around workspace configuration.
  </Card>
</CardGroup>

## Boundaries

Workspace administration APIs should require strong authentication and the right scopes. They should not be available through widget public keys.

Do not expose:

* Provider routing internals.
* Service-role details.
* Hidden model settings.
* Operator-only debug traces.
* Private customer data from another workspace.

## Readiness criteria

* Role and permission behavior is stable.
* Writes are auditable enough for customer admins.
* No-op saves do not grant unnecessary write access.
* Table-backed resources preserve workspace ownership.
* Public responses avoid internal-only configuration.