Skip to main content
POST
Execute an account erasure

Description

ErasurePlan. Before writing, the service:
  1. Re-derives the plan and compares it to the submitted plan (deep, canonicalised equality). Drift returns 409.
  2. Confirms userId and confirmEmail both identify the plan’s subject.
  3. Refuses if any conflict (e.g. sole_owner) is present.
  4. Runs purge/scrub/tombstone inside a transaction with audit hooks suppressed.
Returns 201 when all external surfaces were purged, 207 when the database erasure succeeded but Redis or GCS cleanup partially failed. Requires main_super_admin role. Authorization:
  • Required role: Main Super Admin (system)

Code Examples

Authorizations

Authorization
string
header
required

JWT Authorization header using the Bearer scheme. Format: "Bearer {token}"

Body

application/json
userId
string<uuid>
required

Subject Users.id — the caller's confirmation of who is being erased.

confirmEmail
string<email>
required

Subject's email, echoed by the operator. Hashed and matched against the plan.

plan
object
required
verificationMethod
string
required

How the subject/requester was verified (e.g. email_ownership, support_ticket).

requestSource
enum<string>
default:operator

Compliance classification for the ErasureRecord.

Available options:
self_serve,
support_request,
regulator,
operator
requestedAt
string<date-time>

When the subject asked. Drives retentionExpiresAt; must not be in the future.

Response

Erasure completed (all external surfaces purged)

record
object
required