# Erasure requests

When someone wants their data out of your system, AdPix has a direct path: one organization-level request that deletes that person's events and scrubs their identifying information. This page covers who can raise it, what is actually removed, and what deliberately stays.

## Who can raise one

Erasure runs at the organization level and needs the highest non-platform authority there is: the manage-organization capability, which sits at rank 70 on the role ladder. That means **Org owner** and a platform admin. Every other role gets a `403`.

| Role | Rank | Result |
| --- | --- | --- |
| Org owner | 70 | The request is accepted |
| Org admin | 60 | `403` |
| Account admin | 60 | `403` |
| Property admin | 50 | `403` |
| Editor and below | 40 and under | `403` |

This is the one place where the gap between **Org admin** and **Org owner** actually shows: in day-to-day work the two are nearly identical, but irreversible deletion of data belongs to the owner alone. The full ladder is in [Roles and data restrictions](concepts/governance/roles-and-data-restrictions).

Effective authority comes from the highest role a person holds across their memberships, but the role has to be on **the same organization** the request is raised for. One more thing: if you are signed in through impersonation in read-only mode, the request is refused.

## How the request is made

There is no console screen for this today. The request is an API call made with your own console sign-in session — a server key does not work here, because this path belongs to the management surface, not the collection surface.

```bash
curl -X POST "https://api.adpix.io/api/v1/admin/erasure?organization_id=<ORG>" \
  -H 'Content-Type: application/json' \
  -b 'ap_admin=<your session cookie>' \
  -d '{"email":"person@example.com"}'
```

```bash
curl -X POST "https://api.adpix.io/api/v1/admin/erasure?organization_id=<ORG>" \
  -H 'Content-Type: application/json' \
  -b 'ap_admin=<your session cookie>' \
  -d '{"phone":"+989121234567"}'
```

```json
{
  "ok": true,
  "global_user_id": "…",
  "anonymous_ids_erased": 3,
  "request_id": "erase_…"
}
```

There are three ways to name the person, and one of them is enough:

- `email` — matched against the normalised email.
- `phone` — **in international form, with the country code**. This path does not apply the property's default calling code, so a national form such as `0912…` only matches rows that were themselves stored without a country code.
- `global_user_id` — if you already hold the ID; server-side calls return it in their response, for instance.

| Code | Meaning |
| --- | --- |
| `401` | There is no valid session |
| `400` | `organization_id` is missing, or none of email, phone or global user ID was given |
| `403` | Your role in this organization does not reach the required rank |
| `404` | Nobody with that email or phone was found in this organization |
| `200` | Done; the response carries the global user ID and how many anonymous IDs were erased |

> **There is no undo**
>
> Erasure is a real delete — not a flag, not Trash. Be sure of the organization and of the email or phone before you send it. If the same person is also known in another of your organizations, raise a separate request there; each request reaches one organization only.

## Exactly what is removed

AdPix first resolves the person to one global user in that organization, then collects **every anonymous ID** linked to them by an identity edge — deterministic ones (explicit identify, email bridge, phone bridge, the anonymous seed) as well as probabilistic fingerprint ones. Then it removes:

1. **The raw event archive** for that person, first — because it references events that are about to go.
2. **Their sessions.** This is a separate step because the sessions table is built from events but does not retract itself when events are deleted, and it has to run before the events go, since that is the only place their session IDs can still be found.
3. **The events themselves** in the analytical store, both those under the global user and those under their anonymous IDs.
4. **Neutralising identity-override rows** for each anonymous ID, so that any stray trace resolves to nobody.
5. **Identifying information in the transactional store:** email, email hash, phone hash, CRM client ID and stored traits are cleared on the user row; their emails, phone numbers, profile, identity attribution and identity edges are deleted; and for each anonymous ID, its recorded first touch and fingerprints go too.

From that moment reports no longer return the person. Nothing is queued and there is no nightly job involved.

Each request is written to the audit log as a data-erasure event: who, when, which organization, which global user ID and how many anonymous IDs — never the identifying information itself. That entry is your evidence that it was done.

## What deliberately stays

- **The order attribution row.** Order ID, value, currency, status, the frozen channel snapshot and the **global user ID** all remain. The identifying information behind that ID is scrubbed, so the ID becomes a nameless number. It is a business record and financial reporting leans on it.
- **The emptied user row.** The global user row itself is not deleted, only emptied; it is the anchor the order rows point at.
- **The audit-log entry** for the erasure.
- **Consent records.** The proof of what was chosen and when stays; the IP address in them is hashed and never stored raw.
- **Anything already sent outward.** If you forward events by webhook or a CRM module, an AdPix erasure does not reach that system.
- **Backups taken before the request**, until they are naturally replaced.

## The right order of work

1. Establish which organization the person belongs to and which email or phone they are known by. If they are known under two separate emails that have not been bridged yet, raise a request for each.
2. If all they want is "stop collecting", withdrawing consent or rejecting the statistics category is enough — no erasure needed.
3. Raise the request in that organization and keep the response; it carries the `request_id` and the global user ID.
4. If you forward events to a CRM or another destination, run the deletion there as well.
5. Confirm in the audit log that the erasure entry was written.

AdPix gives you the control and the record. What you have to answer, and within what period, is a decision to take with your own legal counsel.

The automatic lifetime of each class of data — an entirely separate path — is covered in [Data retention](analytics/privacy/data-retention), and the logic that connects an anonymous ID to a person is in [How AdPix identifies visitors](concepts/foundations/how-adpix-identifies-visitors).

## Frequently asked questions

### I am an org admin — why do I get a 403?

Because this action needs Org owner level. Org admin and Account admin share the rank one step below it, so their request is refused. Either your role in that organization has to be raised, or the org owner has to raise the request.

### How soon do reports update after an erasure?

Immediately. The deletion is visible to queries in the analytical store from that moment, so the next report no longer returns the person. There is no nightly job to wait for.

### Can an erasure be undone?

No. It is irreversible. All that remains is the audit-log entry recording who raised it, when, and for which global user ID — never the identifying information itself.

### Do the person's orders disappear from revenue reports?

The order attribution row stays and keeps its global user ID, but the identifying information behind that ID is scrubbed — so inside AdPix the ID no longer leads to a person. That person's own events are deleted from the analytical store.

## Related

- [Data retention](https://docs.adpix.io/en/analytics/privacy/data-retention/)
- [Data retention and deletion](https://docs.adpix.io/en/concepts/governance/data-retention-and-deletion/)
- [Roles and data restrictions](https://docs.adpix.io/en/concepts/governance/roles-and-data-restrictions/)
- [How AdPix identifies visitors](https://docs.adpix.io/en/concepts/foundations/how-adpix-identifies-visitors/)

---

[Docs](https://docs.adpix.io/en/analytics/privacy/erasure-requests/) · AdPix