# user.deleted: your only cleanup signal
Fires when the user is deleted in Clerk, by the user themselves or by an admin. After this, the user cannot sign in and their data is gone from Clerk.
## What to do on receipt
1. Find your local row by `evt.data.id`. The deleted payload is minimal: mostly the id. Do not expect email or name to be present.
2. Delete the row, or anonymize it if your retention policy or regulations require keeping aggregates. Pick one deliberately and do it now; this event does not repeat.
3. Cascade to your own tables: profiles, preferences, sessions, API keys you issued, pending notifications. Anything keyed by the user id or their email should be handled.
4. If you keep billing records, mark them closed and strip PII. Do not leave a live subscription pointing at a deleted user; decide your policy for orphaned subscriptions.
5. Return 200.
## The trap
Waiting for more data. Agents sometimes stall because the payload lacks the email they keyed on. Key everything on the Clerk user id from day one (see the user.created skill), and deletion is a one-line lookup.
## Checklist
- session teardown events may arrive around the same time. Handle user.deleted independently of session events; either order must leave you clean.
- If deletion must also remove data in third-party tools, enqueue those calls and return 200. Do the fan-out async, not in the webhook handler.
- Log the deletion with the event id for your audit trail, minus the PII.