The Platform API does not expose a public endpoint to delete a user or reset onboarding. User records are append-only by design — onboarding events, KYC submissions, agent signers, and Safe wallets all reference the user, and a public reset would invalidate those audit trails.
For local development and demo work, where you need a clean slate to replay onboarding repeatedly, two internal-only paths are available.
Both paths below are internal admin tooling. They are not exposed over the public API and require direct database credentials. Do not attempt to use them in production or against shared environments.
When you need this
- Running a demo end-to-end against a local backend.
- Re-testing onboarding, KYC, or Safe creation flows after an integration change.
- Clearing accumulated test users from a development organisation.
For staging and production, contact your account manager — there is no self-service reset.
Option 1: Delete a single user
A single-user hard delete removes one user and all their dependent records (wallets, accounts, transactions, agent tasks, insights, rules, statuses, cards, and chat sessions) in dependency order, while preserving the user’s organisation, environment, shared reference data, and migration state.
This runs directly against the database and is not exposed over the public API. Ask your account manager (or, if you operate your own backend, your platform team) to run it against your development database.
Option 2: Reset the entire database
A full local reset truncates every domain table while preserving the schema and migration history. Because it is destructive and cannot be undone, restrict it to a database you own and operate it through your platform team rather than the public API.
What the public API does support
GET /v0/user/me returns 404 when no user exists for the current JWT — call POST /v0/user/ to create one.POST /v0/user/ is idempotent: replaying it for an existing user returns 208 Already Reported with the existing record, not an error.
If your demo flow only needs to recover from “user already created”, idempotent retries cover the case without any reset. 
