# Erase an account > Permanently remove an account, block its key, optionally erase its members, and track every part of the erasure. Canonical page: https://anectico.com/docs/manage/erase-a-group/ An account is a company or team connected to your customers. Erasing it is permanent, requires `groups:erase`, and records who asked and why. It does not cancel a billing account. You start an erasure in the Console: open **Privacy** (`/privacy`), stay on the **Requests** tab, and find the account first. See [Erase in the Console](#erase-in-the-console) and the [Console guide](/docs/manage/console#privacy). Your agent can start the same erasure through MCP or the CLI, as the next section shows. The erasure always needs a reason and a typed confirmation. ## Ask your agent > "Find the account of type `company` with key `acme/a` and show me who its active members are." > "Show me the progress of the account erasure I started, including any member that was skipped." | Job | MCP tool or action | CLI command | | --- | --- | --- | | Find an account and read its members | `search_accounts`, `list_account_members` | `anectico accounts get `, `anectico accounts members list ` | | Erase an account | `erase_group` | `anectico accounts erase --reason --yes` | | Read one erasure, or list them | `get_group_erasure`, `list_group_erasures` | `anectico accounts erasures get `, `anectico accounts erasures list` | Finding an account and reading its members need `groups:read`. The three erasure tools need `groups:erase`; erasing members also needs `persons:erase`. `erase_group` previews first and applies on a second call with a `confirm_token`; see [MCP tools](/docs/reference/mcp-tools). The erasure has no proof page: the **Requests** tab of the Console shows its progress, and the tools above return the same state. ## What your agent gets back An erasure read returns the operation id, its state (in progress, **Complete** or **Stalled**), the status of each part, and each saved member decision, including shared members that were skipped and members that were already erased. It shows no erased account key or member aliases. ## What is removed The account's profile and properties, every current or past membership and membership transition, and its account key on product events are removed. Each event stays, together with its person and its other account entries. Account measurements that counted the erased account are withdrawn, and their account rows cannot be listed again. An account measurement that records no individual account is withdrawn if it covers an environment and hour from which the account entry was removed. This conservative rule can withdraw a result that would not have counted the account. Person measurements stay unchanged in the default mode, because no person's event was removed. The profile and memberships are removed when the request returns. Events and measurements are cleaned up in the background. The operation remains **in progress** until every part has finished; do not report the erasure as complete before it says **Complete**. If required work has not finished after 30 minutes, the operation says **Stalled** with an explanation that not every store has finished after the expected time. The account profile and memberships are already removed. Keep the operation ID and contact support or an operator to finish the erasure. Late progress can still complete the same operation; retrying does not restart it. ## What stays By default, people, their profiles and identifiers, their events, recordings and other telemetry stay. Other accounts, other account types and other projects are unaffected, even when their account key has the same spelling. Filters and targeting rules you authored for feature flags, alert segments, saved insights and other configuration stay as your instructions. They can contain a literal account key, but cannot recreate its profile or membership. Experiment assignments and person cohorts stay in the default mode. Past alerts, administrative receipts, the erasure reason and files already downloaded stay too. Do not put account keys or personal identifiers in the reason: it is retained with the operation. ## The key cannot be reused The exact account type/key is permanently blocked in this project. An identify or membership call for it records nothing. A later event stays, but its blocked account entry is stripped. Restoring an older backup must preserve this removal before the account can be served again. Use a different key for a new account. Case, surrounding spaces and all other characters are significant; the same spelling in another project is a different account. “Delete account” is the existing reversible removal of a definition after its active members are detached. “Erase this account” performs the permanent operation described here. ## Also erase members Members are optional and require `persons:erase` as well. Active membership is saved when the erasure is requested. Multiple identifiers of one person produce one child [person erasure](/docs/manage/erase-a-person), which removes that person's full identity and data described there. Inactive historical memberships do not add people to this snapshot. A person with another active account of the **same type in this project**, under any of their identifiers, is shared. They are skipped and reported unless you select **Include shared members too**. A different account type or project does not make them shared. The parent operation completes only when every member erasure it requested is complete. If a saved member was already erased separately, their child is recorded as already erased and names the earlier satisfying operation. If a saved member has since merged into another person, their erasure follows that recorded merge and removes the person they became. If neither the member nor a recorded merge or earlier erasure can be found, the operation says **Member missing**, stays incomplete, and shows the saved person reference. Keep that reference and the operation ID for support or an operator to investigate. No other person is chosen. Another person using the same spelling as an identifier is never substituted for that saved member. The request supports at most **256 active membership edges**, hence at most 256 people. Identifiers count toward that bound even if several belong to one person. A person can have at most 1,000 identifiers for this operation. Above either limit, or if a member cannot be resolved completely, the **entire request is refused**: nothing is erased or blocked. Choose account-only erasure or resolve the membership before retrying. There is no partial run. ## Erase in the Console 1. In the Console, open **Privacy** (`/privacy`) and stay on the **Requests** tab. 2. In the **An account** card, enter the account type and the account key, then choose **Find account**. The page looks the account up first, and the erase control appears only for an account it finds. 3. Choose **Erase this account**. Read the removal boundary, supply a reason, and choose **Also erase its members** if you need it. Choose **Include shared members too** only if you mean to erase people who also belong to another account of the same type. 4. Type **erase** exactly to confirm. The **Account erasures** section of the same tab lists progress, child operation IDs and shared-member skip decisions. It shows no erased account key or member aliases. A missing member shows only the saved person reference needed to investigate the incomplete erasure. ## REST, MCP and CLI REST uses `POST /api/v1/projects/{projectId}/group-erasures`. Send the account type and key as exact JSON strings. `.`, `..`, `a/b` and the literal `%2F` are ordinary values; no URL escaping is needed. Preserve spaces, case and Unicode. The type must contain 1–200 UTF-8 bytes and the key 1–1,024 UTF-8 bytes. Malformed UTF-8 and NUL characters are refused before erasure begins. A credential bound to a different project is refused before the operation runs. ```json { "group_type": "company", "group_key": "acme/a", "operation_id": "33333333-3333-4333-8333-333333333333", "reason": "Request 88", "mode": "GROUP_ERASURE_MODE_GROUP_ONLY", "include_shared_members": false } ``` Omitting `mode` keeps people. To erase members, use `GROUP_ERASURE_MODE_WITH_MEMBERS`; `include_shared_members` is valid only with that mode. Read progress with `GET /api/v1/projects/{projectId}/group-erasures/{operationId}` or list operations with `GET /api/v1/projects/{projectId}/group-erasures?limit=50`. Lists accept 1–200 operations and an unchanged `next_cursor` as the next request's `cursor`. MCP exposes `erase_group` through the write-action confirmation flow. It takes `group_type`, `group_key`, `operation_id` and `reason`, with optional `with_members` and `include_shared_members`. The preview explains the choice; member membership is saved at request time. Read actions are `get_group_erasure` and `list_group_erasures`. ```bash anectico accounts erase company 'acme/a' --reason 'Request 88' --yes anectico accounts erasures get anectico accounts erasures list --limit 50 ``` Add `--with-members` to erase members and `--include-shared-members` to include shared people. The CLI prints a generated operation ID before sending. To recover from a lost response, repeat the same request with `--operation-id `. Never change the intent while reusing an operation ID. All three routes and read actions require `groups:erase`. Reading an operation uses that permission because it includes the requester and their reason. Project-scoped credentials can act only in their project. Audits name the operation ID, so they do not preserve the account key you erased.