Skip to content
Console
Browse documentation
Guide

Erase an account

Permanently remove an account, block its key, optionally erase its members, and track every part of the erasure.

On this page

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 and the Console guide. 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 <group-type> <group-key>, anectico accounts members list <group-type> <group-key>
Erase an account erase_group anectico accounts erase <group-type> <group-key> --reason <text> --yes
Read one erasure, or list them get_group_erasure, list_group_erasures anectico accounts erasures get <operation-id>, 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. 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, 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.

{
  "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.

anectico accounts erase company 'acme/a' --reason 'Request 88' --yes
anectico accounts erasures get <operation-id>
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 <that-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.