---
title: "Delete Account"
method: DELETE
path: "/auth/me"
tags: ["auth"]
---

# Delete Account

`DELETE /auth/me`

## Request

- Base URL: `https://api.nicheangle.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.nicheangle.com/auth/me`
- Auth: none declared

Hard-delete the user's account end-to-end.

Order of operations:
  1. Best-effort cancel any active Stripe subscription (logged,
     non-fatal — a dangling sub is reconcilable; a half-deleted
     account is not).
  2. Delete every row the user owns, children-before-parents, in a
     single transaction. FK CASCADE is inconsistent across child
     tables (credits/api_keys/modules/oauth cascade; sessions,
     outputs, brand_*, etc. do NOT) so we delete explicitly. Session-
     keyed children (outputs, story_picks, scheduled_posts) go before
     their parent sessions. On any DB error we roll back — the user
     keeps a working account rather than a half-deleted one.
  3. Delete the app User row (cascading children clean up here).
  4. Delete the Supabase auth user via the admin API. Best-effort:
     the app data is already gone, so a failure here leaves an
     orphaned auth identity that we log for manual cleanup but still
     return success.

`users.id` equals the Supabase auth uid — CurrentUser.id comes
straight from the Supabase token `id` claim (see app/auth.py
`_verify_supabase_bearer_token`), and `_ensure_user` writes the row
with that same id. So the same UUID drives both the app deletes and
the Supabase admin delete.

## Headers

- `authorization` string, nullable

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/nicheangle/apis/signal-api.md) · [All operations](https://skmtc.dev/nicheangle/apis/signal-api/llms.txt) · [OpenAPI document](https://skmtc.dev/nicheangle/apis/signal-api/revisions/ed8b47ff5891?raw)