Create DROP erasure requests via API
The DROP API lets you create DROP-sourced erasure requests directly, for organizations that process their own DROP work items outside Astralis but still want the resulting deletions centrally tracked alongside Astralis. Every request with source: "DROP" must use an erasure-only policy.
This is a separate, lighter-weight path from the Setup, match index, and suppression cycles pipeline: it doesn't require a DROP connector, a Snowflake match index, or scheduled cycles, and it doesn't write to the suppression ledger. It simply creates a normal erasure privacy request tagged source: "DROP", which Astralis auto-approves and surfaces in the DROP cycles tab like any other DROP-sourced erasure request.
Prerequisites
- An erasure policy — the request policy used for the request.
source: "DROP"is only accepted on erasure policies. - An OAuth client with the scopes below. See Creating OAuth Clients.
Required permissions
| Scope | Grants |
|---|---|
privacy-request:create | Create the erasure privacy request |
privacy-request:create-drop | Allow the reserved source: "DROP" value on erasure request creation |
The built-in Owner role includes privacy-request:create-drop; Contributor does not. Grant it explicitly to any client that needs to create DROP-sourced requests, since it unlocks the DROP auto-approval exemption.
Create a DROP-sourced erasure request
Send a request to the authenticated privacy request endpoint with the source: "DROP" property:
[
{
"source": "DROP",
"policy_key": "my-erasure-policy",
"external_id": "broker-record-482",
"identity": {
"email": "identity@example.com"
}
}
]The endpoint accepts the same fields as the standard privacy request body. source: "DROP" is only accepted on this authenticated endpoint — the public, unauthenticated endpoint always rejects it. The endpoint also accepts a bulk array. Every DROP item must resolve to an erasure-only policy; non-DROP items in the same array are validated under their own rules, and each item succeeds or fails independently.
Astralis applies these rules to every source: "DROP" item:
| Rule | Behavior |
|---|---|
| Erasure only | Rejected if the resolved policy isn't erasure-only. |
Reserved external_id namespace | Rejected if external_id starts with drop: — that prefix is reserved for requests minted by suppression cycles. |
| Idempotent replay | Re-posting the same external_id from the same client, with the same policy and identity, returns the original request rather than creating a duplicate. |
external_id from a different client, policy, or identity is rejected rather than returned — this keeps one integration from reading another's request by guessing or reusing an external_id. Verify the erasure request
Confirm the response places the request in the succeeded array and does not include it in failed. The succeeded object should show your external_id, source: "DROP", and status: "approved".
To verify the erasure request later, filter privacy requests by the same external ID:
Errors
| Response | Cause |
|---|---|
| A per-item error naming the missing scope | The client token doesn't carry privacy-request:create-drop. |
| A per-item policy error | The resolved policy isn't erasure-only. |
| A per-item namespace error | external_id starts with drop:. |
| A per-item collision error | external_id matches an existing DROP erasure request from a different client, policy, or identity. |
Auto-approval and visibility
API-created DROP erasure requests auto-approve the same way as cycle-minted ones — see Approve and deny privacy requests. They also make the DROP cycles tab visible in Request manager, even when no DROP connector is configured.
Track processing the same way as any other erasure privacy request — see Monitor ongoing requests.