{% callout type="info" heading="Using the v1 API?" %}
If your integration still uses `/api/2/deletions/users` on `amplitude.com`, see the [User Privacy API](/docs/apis/analytics/user-privacy) documentation. This page documents v2, hosted at `privacy.amplitude.com`.
{% /callout %}

## What's new in v2

If you're already integrated with v1, the most important change is how deletion scope is interpreted. v1 defaulted to single-app (project) deletion when scope was unspecified. v2 always deletes across your entire organization.

| Area | v1 (legacy) | v2 (current) |
| ---- | ----------- | ------------ |
| Default scope | Single project | Org-wide (all projects) |
| Scope control | Set `delete_from_org: true` for org-wide deletion | Not applicable — all requests delete from org |
| Endpoint | `POST /api/2/deletions/users` for create, `GET` for status, `DELETE` to remove from staging | `POST privacy.amplitude.com` for create, `GET` for status, `DELETE` to remove from staging |

{% callout type="note" heading="delete_from_org is v1 only" %}
The `delete_from_org` parameter exists only on the [legacy v1 API](/docs/apis/analytics/user-privacy). It is **not** supported on v2. All deletion requests submitted to `privacy.amplitude.com` delete user data across every project in your organization.
{% /callout %}

## Endpoints

| Operation | Method | Path |
| --------- | ------ | ---- |
| Submit deletion job | `POST` | `privacy.amplitude.com` |
| Get job status | `GET` | `privacy.amplitude.com?start_day=YYYY-MM-DD&end_day=YYYY-MM-DD` |
| Remove a user from a staging job | `DELETE` | `privacy.amplitude.com/{AMPLITUDE_ID}/{JOB_START_DAY}` |

## Regions

The base URL depends on your project's data residency. In all examples on this page, use the default base URL unless your project uses Amplitude's EU data center—in that case use the EU base URL in this table.

| Data residency | Base URL |
| -------------- | -------- |
| Default | `https://privacy.amplitude.com` |
| EU | `https://privacy.eu.amplitude.com` |

Use the host that matches your project's data residency.

## Authentication

HTTP Basic auth with your **project API key + secret key**, base64-encoded as `{api_key}:{secret_key}`.

```http
Authorization: Basic <base64(api_key:secret_key)>
```

The API key identifies the project the request originates from. Deletion still applies org-wide across all projects (see [Org-wide deletion](#org-wide-deletion)).

{% callout type="note" heading="DSAR is separate" %}
Data Subject Access Requests use a different endpoint (`/api/2/dsar/requests`) and require an **org-level** API key. Contact Amplitude Support to provision one.
{% /callout %}

## Submit a deletion job

`POST privacy.amplitude.com`

Add users for deletion using a JSON body. Specify up to 100 users at a time. You can use a mix of Amplitude IDs and User IDs. Every request deletes user data across your entire organization.

### Body parameters

| Field | Type | Required | Description |
| ----- | ---- | -------- | ----------- |
| `amplitude_ids` | `int[]` | At least one of `amplitude_ids` or `user_ids` | Amplitude IDs to delete. Up to 100 total IDs across both arrays. |
| `user_ids` | `string[]` | At least one of `amplitude_ids` or `user_ids` | User IDs to delete. Up to 100 total IDs across both arrays. |
| `requester` | `string` | Yes | Email of the person submitting the request. Used in audit emails. |
| `ignore_invalid_ids` | `boolean` | No (default `false`) | If `true`, the job proceeds even if some IDs aren't found. If `false`, the request fails on any unknown ID. |
| `include_mapped_user_ids` | `boolean` | No | If `true`, also deletes data associated with mapped user IDs (Portfolio add-on). |

{% callout type="note" %}
`delete_from_org` is not a valid parameter on v2. It is a [v1-only](/docs/apis/analytics/user-privacy) option to opt into org-wide deletion. On v2, org-wide deletion is the default and only behavior.
{% /callout %}

{% accordion title="Example: Submit a deletion request" %}

```bash
curl --request POST 'https://privacy.amplitude.com' \
  -u 'API_KEY:API_SECRET' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "amplitude_ids": [123123, 543221],
    "user_ids": ["user_1"],
    "requester": "privacy@yourcompany.com"
  }'
```

Amplitude creates one deletion job per project that contains data for any of the specified users. All account admins are emailed with details, including the specific Amplitude IDs scheduled for deletion.

{% /accordion %}

## Check job status

`GET privacy.amplitude.com?start_day=YYYY-MM-DD&end_day=YYYY-MM-DD`

```bash
curl --request GET 'https://privacy.amplitude.com?start_day=2026-05-01&end_day=2026-05-31' \
  -u 'API_KEY:API_SECRET' \
  --header 'Accept: application/json'
```

Returns all deletion jobs scheduled within the date range. Maximum range is six months.

### Job lifecycle

| State | Meaning |
| ----- | ------- |
| `staging` | Job created but not yet locked in. Editable / revocable. |
| `submitted` | Job locked. Runs on the scheduled date. Cannot be modified. |
| `done` | Deletion completed across all systems including backups. |

A job moves from `staging` to `submitted` **3 days before** its scheduled run date. Up until that point you can remove a specific user from the job using the DELETE endpoint:

```bash
curl --request DELETE \
  'https://privacy.amplitude.com/{AMPLITUDE_ID}/{JOB_START_DAY}' \
  -u 'API_KEY:API_SECRET'
```

After a job becomes `submitted`, it cannot be canceled.

## Org-wide deletion

All v2 deletion requests are org-wide. When you submit a request, Amplitude fans the deletion out to every project in the organization that contains data for the listed users.

- One deletion job is created for each project that has matching data.
- All account admins receive an email with the full list of Amplitude IDs scheduled for deletion across the org.

There is no project-scoped deletion mode on v2. If you need to delete from a single project only, use the [legacy v1 API](/docs/apis/analytics/user-privacy) without setting `delete_from_org`.

If you previously used v1 without setting `delete_from_org`, your historical deletion requests may have only deleted from a single project. Re-submit those users through v2 to ensure org-wide deletion.

## Service-level commitments and timing

| Commitment | Value |
| ---------- | ----- |
| Maximum deletion completion time | 30 days from request |
| Job revocable until | 3 days before scheduled run date |

When you make a deletion request, Amplitude [emails all account admins](https://help.amplitude.com/hc/en-us/articles/360031965572-Manage-user-privacy-notifications-in-Amplitude) with the deletion details.

## Important behaviors

### Deletion doesn't stop future tracking

The User Privacy API removes existing data. It does **not** prevent Amplitude from accepting new events for the deleted user. If your SDK continues to send events for them, those events are ingested as a brand-new user. Amplitude has no memory of the deleted identity to re-link against.

To stop future tracking, use the `setOptOut()` method on the Amplitude SDK you're using.

### Warehouse / CDC reingestion

If you ingest data into Amplitude from a data warehouse through Change Data Capture (CDC) or other warehouse-native ingestion methods, deletion in Amplitude does not propagate back to the source. On the next sync, the deleted data may be reingested.

**To ensure complete deletion, delete the data in your warehouse source as well, then re-run the User Privacy API request.** This applies to:

- Snowflake / BigQuery / Databricks / Redshift CDC sources
- Mirror Sync
- Any other warehouse-native ingestion path

### Future event identity

After a deletion, if new events arrive for the same `user_id`, they are treated as a new user with a fresh Amplitude ID. There is no automatic re-stitching.

### Statsig data

This User Privacy API only deletes data from the Amplitude platform. To delete data from the Statsig platform, use the [Statsig User Data Deletion Requests API](https://docs.statsig.com/compliance/user_data_deletion_requests).

## Migrating from v1

If you have an existing v1 integration, see the [v1 documentation](/docs/apis/analytics/user-privacy) for the legacy endpoint reference. Here's what to change when moving to v2:

### 1. Update your endpoint

```diff
- POST https://amplitude.com/api/2/deletions/users
+ POST https://privacy.amplitude.com
```

Apply the same host change to your `GET` and `DELETE` requests.

### 2. Batch your requests

v2 accepts up to 100 IDs per request. Batch IDs in each request to delete users efficiently.

### 3. Remove delete_from_org

The `delete_from_org` parameter is v1-only. On v2, all requests delete org-wide by default — you don't need to (and can't) set this flag.

```diff
  {
    "user_ids": ["user_1"],
    "requester": "privacy@yourcompany.com",
-   "delete_from_org": true
  }
```

If you were using v1 **without** `delete_from_org`, your requests only deleted from a single project. Migrating to v2 automatically upgrades those requests to org-wide deletion.

### 4. Use job status visibility

v2 exposes a GET endpoint that returns the full lifecycle state of your deletion jobs (`staging` / `submitted` / `done`).

## Status codes

| Code | Message |
| ---- | ------- |
| 200 | Success |
| 400 | Bad Request |
| 401 | Unauthorized |