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

# Roles and Permissions in Pilot Status

> Owner, Admin, Agent and Analyst — what each role can do in a Pilot Status workspace, and why the Analyst deliberately cannot read conversations.

Every member of a workspace has exactly one role. The role decides what they see and what they can do, and it is checked on the server on every request — hiding a button is a courtesy, not the protection.

## The four roles

<CardGroup cols={2}>
  <Card title="Owner" icon="crown">
    Owns and pays for the workspace. The only role that moves money, reveals credentials in plaintext, destroys numbers permanently, and changes who is inside.
  </Card>

  <Card title="Admin" icon="sliders">
    Runs the day to day. Everything except money, plaintext credentials and irreversible destruction.
  </Card>

  <Card title="Agent" icon="messages">
    Serves customers. Lives in Chat and Labels: reads conversations, sends messages, handles calls.
  </Card>

  <Card title="Analyst" icon="chart-simple">
    Looks at the numbers. **Deliberately cannot open conversations** — see below.
  </Card>
</CardGroup>

## What each role can do

|                                                         | Owner | Admin | Agent | Analyst |
| ------------------------------------------------------- | :---: | :---: | :---: | :-----: |
| See the workspace, its numbers and templates            |   ✅   |   ✅   |   ✅   |    ✅    |
| See logs and analytics                                  |   ✅   |   ✅   |   ✅   |    ✅    |
| Open conversations, read message content                |   ✅   |   ✅   |   ✅   |    —    |
| Send messages, handle calls, manage contacts and labels |   ✅   |   ✅   |   ✅   |    —    |
| Connect, rename and disconnect numbers                  |   ✅   |   ✅   |   —   |    —    |
| Create and edit templates                               |   ✅   |   ✅   |   —   |    —    |
| Configure webhooks and integrations                     |   ✅   |   ✅   |   —   |    —    |
| Invite members, see the member list                     |   ✅   |   ✅   |   —   |    —    |
| Rotate API keys, see the key list                       |   ✅   |   ✅   |   —   |    —    |
| Resend a failed message                                 |   ✅   |   ✅   |   —   |    —    |
| See the invoice and the plan                            |   ✅   |   ✅   |   —   |    —    |
| Change the plan, top up the wallet, manage the card     |   ✅   |   —   |   —   |    —    |
| Reveal an API key in plaintext                          |   ✅   |   —   |   —   |    —    |
| Change someone's role, remove a member                  |   ✅   |   —   |   —   |    —    |
| Delete a number permanently                             |   ✅   |   —   |   —   |    —    |
| Transfer ownership, archive the workspace               |   ✅   |   —   |   —   |    —    |

## Why the Analyst cannot read conversations

This is the one line in the table that surprises people, and it is the point of the role.

An analyst who can open every customer conversation has read the personal data of every customer you have — names, phone numbers, documents, complaints, whatever people type into WhatsApp. The Analyst role exists precisely so that someone can look at volume, delivery rates and cost **without** that exposure.

If your analyst also needs to read conversations, the honest answer is that they are an Agent.

## Scoping someone to specific numbers

Agents and Analysts can be limited to a subset of the workspace's numbers. Someone scoped to two numbers sees only those two in the selector, and requests touching a third are refused by the server, not just hidden.

Owners and Admins are always workspace-wide. Their work — connecting numbers, buying capacity, rotating keys — is not something a per-number limit can express, and pretending otherwise would show a restriction the server does not enforce.

## Roles and the API

Machine credentials do not have roles. An API key or an OAuth token carries **scopes**, and what it can reach is decided by those — not by a workspace role. One consequence is worth stating plainly: writing to the member list is never allowed with a classic API key, only with OAuth, because an `x-api-key` request has no user behind it. See [the workspace API](/api/workspace).
