---
title: "Create Erasure Request"
method: POST
path: "/api/v1/me/account/erasure-request"
tags: ["account-erasure"]
---

# Create Erasure Request

`POST /api/v1/me/account/erasure-request`

## Request

- Base URL: `https://memory.kagura-ai.com` (the document declares no server; this is the origin it was published from)
- URL: `https://memory.kagura-ai.com/api/v1/me/account/erasure-request`
- Auth: none declared

Create a pending erasure request and issue a one-time token.

Returns 201 with the new request's state. The ``confirm_token`` field
in the response is populated for password-auth users and ``null`` for
OAuth users (Issue #469): OAuth users receive the token via email
instead, keeping the raw secret out of the response surface.

Other status codes:
    - 403: user is the protected initial admin
    - 409: an active erasure request already exists for this user
      (``ERASURE-006``), or the user owns a workspace with a running
      paid subscription (``BILLING-005``, Issue #1940)
    - 503: OAuth user but the confirmation email failed to dispatch
      (mapped from EmailDispatchError); the pending row is rolled back
      so the user can retry once the email backend recovers.

The receipt notification (separate from the OAuth confirmation email)
is dispatched post-commit and is fire-and-forget — it tells the user
the request was received and is meant to be obvious to the human even
if they don't click any confirm link.

## Headers

- `authorization` string, nullable

## Response `201`

Successful Response

- ErasureRequestCreateResponse: Returned after creating a self-service erasure request. The confirmation token is delivered through one of two channels depending on whether the account has a password (Issue #469; since #1678 an OAuth account that added a password counts as a password user): - **Users with a password**: ``confirm_token`` is populated in this response. The user re-enters their password alongside this token at ``POST /me/account/erasure-confirm`` (the password is the second factor — the response token is the first). - **Users without a password**: ``confirm_token`` is ``None`` here. The token is delivered via email to the user's account address as a one-time confirm link. Email is the canonical second factor for OAuth, just as the password re-prompt is for password-auth users — keeping the raw token out of the response body removes a redundant copy that would otherwise widen the disclosure surface (proxy access logs, browser devtools, frontend error-reporters) once email actually delivers it. The raw token is stored in Redis under ``erasure_token:{token}`` with a 1-hour TTL and is single-use regardless of delivery channel. The Redis key maps token → ``request_id`` only — it is NOT session-bound. Confirmation additionally requires the authenticated session user to match the erasure request's ``user_id`` (enforced by ``confirm_self_service``), so a leaked token alone is insufficient without the matching session cookie. The frontend SHOULD treat this token as sensitive and not log it.
  - `request_id` unknown, required
  - `status` unknown, required
  - `requested_at` unknown, required
  - `confirm_token` unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/kagura-ai/apis/kagura-memory-cloud.md) · [All operations](https://skmtc.dev/kagura-ai/apis/kagura-memory-cloud/llms.txt) · [OpenAPI document](https://skmtc.dev/kagura-ai/apis/kagura-memory-cloud/revisions/09f17f5ada29?raw)