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

# Managing Workspace Members in Pilot Status

> Invite teammates, resend or revoke invitations, change roles, and understand what happens to a member's API keys when they leave.

Members live in **Profile → Members**. The tab appears only for roles that can see it (Owner and Admin).

## Inviting someone

Type the e-mail, pick a role, send. The person receives an e-mail with a link that is valid for **7 days**.

<Warning>
  The invitation link is shown **once**, right after you send it, and never again — we store only a hash of it, so we could not show it a second time even if we wanted to. If you lose it, use **Resend**: that issues a new link and kills the old one.
</Warning>

That is also the escape hatch when e-mail is not an option: copy the link and deliver it however you like.

Two rules the form enforces:

* **Owner is never assignable.** Becoming the owner is a transfer of ownership, with its own confirmation.
* **An Admin can invite Agents and Analysts, not other Admins.** Creating an Admin changes who is in charge, and that is the owner's call.

## Seats

The counter at the top shows seats in use. A **pending invitation occupies a seat** until it is accepted or expires — otherwise you could invite thirty people and discover it on the invoice.

An expired invitation frees its seat by itself. Nothing to clean up, no job to run.

Every plan on sale includes at least two seats: **Free covers the owner plus one guest**, so the first invitation goes through and the second is where the paywall starts. Paid plans start at three.

A single-seat workspace is therefore not something a plan produces any more — it only happens when a seat limit is set explicitly below two. In that case the invite form is replaced by a link to the plans page. The server refuses either way; the form just does not waste your time.

## Resending and revoking

**Resend** issues a new link and invalidates the previous one. It works even when the workspace is out of seats — the pending invitation already holds its seat, so resending does not need a new one.

**Revoke** is the same action as removing a member: one button, because an invitation and a membership are the same row underneath. Pending rows show a *Revoke* button; active ones show *Remove*.

## Changing a role

Change the role from the row. The change takes effect on the person's next request — there is no cache to wait out and no need for them to sign in again.

Scoping an Agent or Analyst to specific numbers is done in the same place. Promoting someone to Admin clears that scope, because Admins are workspace-wide by definition.

## Removing someone — and their API keys

Removing a member takes effect immediately: their OAuth and MCP tokens stop working on the next call, and any refresh tokens they hold are revoked, so nothing can resurrect the old access.

**API keys are different, and Pilot Status will stop and ask.** If the person created API keys that are still in use, the removal is blocked and you are shown each key — its name, its last four characters, when it was last used — with two explicit choices:

<CardGroup cols={2}>
  <Card title="Revoke the keys" icon="ban">
    The keys stop working immediately. Anything integrating through them breaks now.
  </Card>

  <Card title="Keep the keys" icon="key">
    The keys keep working and are reassigned to you. Nothing breaks; you now own them.
  </Card>
</CardGroup>

There is no default, on purpose. Revoking silently takes down production integrations in the middle of an offboarding; leaving keys orphaned is worse, because they keep working and nobody knows whose they are.

<Note>
  Revoking a key never deletes it — the record stays so that message and call history keeps pointing somewhere real. A revoked key simply stops authenticating.
</Note>

## Accepting an invitation

The invited person opens the link and signs in. **The e-mail on the account must match the e-mail that was invited** — otherwise anyone who intercepted the link could join with their own account, and the invitation would stop being nominal.

The link then shows what is being offered — the workspace, the role, and the address the invitation was sent to — and asks. **Opening the link does not join anything**; accepting is a deliberate click.

Once accepted, the workspace becomes the active one right away. It stays available in the workspace switcher from then on.

### Declining

The same screen offers **Decline**, behind a confirmation because it cannot be undone from the invitee's side: declining burns the link, and getting in later means being invited again.

Whoever sent the invitation sees the row turn into **"Convite recusado"** — which is the point of the state existing. A declined invitation and a revoked one used to be indistinguishable, and the difference is what decides between resending and having a conversation.

A declined invitation releases its seat immediately.

## Doing this from the API

Every action above has an API equivalent under `/v1/workspace`. Writing to the member list requires OAuth, not a classic API key — see [the workspace API](/api/workspace) for why.