User Privacy API v2

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.

Endpoints

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.

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}.

Authorization: Basic <base64(api_key:secret_key)>

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

Check job status

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

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

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:

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.

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

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

Migrating from v1

1. Update your endpoint

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

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