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

# Overview

> Manage Enterprise Team members programmatically from your IDP (SailPoint, Okta, custom integrations)

<sup>Questions or issues? Contact us at [api-support@manus.ai](mailto:api-support@manus.ai).</sup>

# Team User Management

Lets enterprise tenant administrators **provision, modify, and offboard team members** from external identity systems. Built for SCIM-style automation: account aggregation, role updates, lifecycle (active / inactive / removed), and the **Profile Migration** workflow for taking ownership of a deactivated colleague's data.

## Endpoints

<CardGroup cols={2}>
  <Card title="List team members" icon="list" href="/enterprise/v2/team.user.list">
    Page through team members with status / delegation filters
  </Card>

  <Card title="Get member detail" icon="user" href="/enterprise/v2/team.user.detail">
    Look up a single member by email or `team_user_id`
  </Card>

  <Card title="Add a member" icon="user-plus" href="/enterprise/v2/team.user.create">
    Create a new team member, auto-provisioning the underlying personal account if needed
  </Card>

  <Card title="Update status / role" icon="user-pen" href="/enterprise/v2/team.user.update">
    Activate, deactivate, or change role; cascading reclaim of delegated profiles when deactivating
  </Card>

  <Card title="Delegate a profile" icon="arrow-right-arrow-left" href="/enterprise/v2/team.user.delegate">
    Hand a deactivated profile to an active member so they can take over its data
  </Card>

  <Card title="Reclaim a profile" icon="rotate-left" href="/enterprise/v2/team.user.reclaim">
    Return a delegated profile to the deactivated pool
  </Card>

  <Card title="Rename a profile" icon="pen" href="/enterprise/v2/team.user.rename">
    Update a profile's display name (useful for delegated profiles)
  </Card>

  <Card title="Remove a member" icon="user-minus" href="/enterprise/v2/team.user.remove">
    Permanently remove a team member; cascading reclaim of delegated profiles
  </Card>
</CardGroup>

## User lifecycle

```
ACTIVE ⇄ INACTIVE → REMOVED  (terminal, hard delete)
            ↑
         (delegated profiles live here until reclaimed or re-delegated)
```

* **ACTIVE** — full access. Can be promoted/demoted via [team.user.update](/enterprise/v2/team.user.update) (except `OWNER`, which is API-immutable).
* **INACTIVE** — disabled. Once inactive, a profile becomes eligible for delegation via [team.user.delegate](/enterprise/v2/team.user.delegate).
* **REMOVED** — terminal. Hard-deletes the user; cascades to reclaim profiles delegated to them.

## Profile delegation

When an employee leaves, their account is deactivated and may then be **delegated** to an active teammate so the teammate can keep working on the data:

1. [team.user.update](/enterprise/v2/team.user.update) sets `status: USER_STATUS_INACTIVE` on the departing employee.
2. [team.user.delegate](/enterprise/v2/team.user.delegate) hands `team_user_id` to `target_team_user_id`. The delegated profile's email is rewritten to `delegate-<id>@manus.im`; the original is preserved in `original_email`.
3. [team.user.rename](/enterprise/v2/team.user.rename) (optional) gives the delegated profile a human-readable label.
4. [team.user.reclaim](/enterprise/v2/team.user.reclaim) returns the profile to the deactivated pool — no data loss; can be re-delegated later.

Removing or deactivating an assignee automatically reclaims everything delegated to them; the affected profiles are returned in `cascade_affected[]`.

## Operational notes

* **Authentication:** `X-API-Key` with key type **Team User Management**. See [Authentication](/enterprise/v2/authentication).
* **Owner is read-only:** The team owner cannot be modified, deactivated, removed, or downgraded via the API. Transfer ownership in the UI first.
* **`team_user_id` is the stable handle:** Once a profile is delegated, its email becomes `delegate-<id>@manus.im`. Cache the `team_user_id` from your initial `team.user.create` / `team.user.list` response and use it for every subsequent profile operation.
* **Guest role does not consume a seat:** Promoting `GUEST → MEMBER/ADMIN/SUPER_ADMIN` via [team.user.update](/enterprise/v2/team.user.update) calls Stripe to bump seat quantity; the reverse direction releases the seat implicitly. A Stripe failure during a paid promotion surfaces as `internal` and the role change is rolled back.
* **Audit logging:** Every call writes to the shared enterprise audit log, correlated by `request_id` from the response envelope.