POST /api/v1/gdpr/erasure
Permanently deletes all records associated with a customer ID across five data tables in a single atomic transaction. This implements the GDPR “right to erasure” (right to be forgotten) as defined in Article 17 of the General Data Protection Regulation.
The deletion is transactional — either all tables are cleaned or none are, ensuring no partial erasure. An audit log entry is recorded after successful erasure to maintain a compliance trail (the audit entry records that an erasure occurred but does not retain the deleted data).
Authentication
Requires a valid tenant and the admin role.
| Header | Required | Description |
|---|
X-Tenant-Id | Yes | Tenant identifier |
Authorization | Yes | Bearer token or API key |
This operation is irreversible. All interaction history, decision traces, suppressions, attribution results, and interaction summaries for the specified customer will be permanently deleted. There is no undo.
Request Body
{
"customerId": "CUST001"
}
| Field | Type | Required | Description |
|---|
customerId | string | Yes | The unique identifier of the customer whose data should be erased |
Example Request
curl -X POST https://playground.kaireonai.com/api/v1/gdpr/erasure \
-H "Content-Type: application/json" \
-H "X-Tenant-Id: my-tenant" \
-H "Authorization: Bearer sk_live_abc123" \
-d '{
"customerId": "CUST001"
}'
Example Response
{
"success": true,
"customerId": "CUST001",
"deletedCounts": {
"interactionHistory": 142,
"interactionSummary": 12,
"suppression": 8,
"decisionTrace": 37,
"attributionResult": 23
},
"totalDeleted": 222
}
Response Fields
| Field | Type | Description |
|---|
success | boolean | true if the erasure completed successfully |
customerId | string | The customer ID that was erased |
deletedCounts | object | Breakdown of records deleted per table |
deletedCounts.interactionHistory | integer | Number of interaction history records deleted (impressions, clicks, outcomes) |
deletedCounts.interactionSummary | integer | Number of interaction summary records deleted (aggregated interaction stats) |
deletedCounts.suppression | integer | Number of suppression records deleted (frequency cap and cooldown entries) |
deletedCounts.decisionTrace | integer | Number of decision trace records deleted (forensic traces of pipeline execution) |
deletedCounts.attributionResult | integer | Number of attribution result records deleted (outcome-to-recommendation mappings) |
totalDeleted | integer | Sum of all deleted records across all tables |
Tables Affected
The erasure targets these five customer-scoped tables within the tenant boundary:
| Table | Description |
|---|
InteractionHistory | Raw interaction events (impressions, clicks, conversions, dismissals) |
InteractionSummary | Aggregated interaction statistics per customer-offer pair |
Suppression | Active suppression rules (frequency caps, cooldown periods) |
DecisionTrace | Forensic traces of the decision pipeline for debugging and auditing |
AttributionResult | Links between outcomes and the recommendations that generated them |
All deletions are scoped to both the tenantId and customerId, so no cross-tenant data is affected.
Audit Trail
After a successful erasure, an audit log entry is created with:
- action:
gdpr_erasure
- entityType:
customer
- entityId: The erased customer ID
- changes: The
deletedCounts breakdown
This entry appears in the Change History feed and can be filtered with action=gdpr_erasure.
Error Responses
| Status | Cause |
|---|
400 | Missing customerId, invalid JSON body, or customerId is not a string |
401 | Missing or invalid authentication credentials |
403 | Insufficient role (requires admin) |
500 | Erasure transaction failed (no data was deleted — the transaction rolls back entirely) |
If the customer has no data in any of the five tables, the endpoint still returns success: true with all counts at 0. This is expected behavior — the erasure request is idempotent.
The GDPR erasure endpoint does not delete customer records stored in external data sources (e.g., schema tables populated via connectors or pipelines). If your tenant stores customer PII in custom schema tables, you must handle erasure for those tables separately.
See also: Change History | Interaction History | Decision Traces