Let users delete their own account

Sooner or later one of your users asks how to delete their account. Until now the answer went through you: they emailed support, and someone erased them from the panel or from a backend route that held an operator key. Now the signed-in user can make one call, DELETE /api/v1/users/me, and Rekey runs the same erasure an operator would.

This post covers the setting that decides who may make that call, the call from a browser and from your server, the cases where it is refused, and what erasure removes and keeps.

Choose who may delete an account

Each Application has an accountDeletion setting in its auth config. In the panel it is Authentication → Methods → Account deletion.

A refusal from this setting is 403 ACCOUNT_SELF_DELETION_DISABLED. It is checked before the password, so an Application with deletion turned off never tells a caller whether a password was right. The same field can be set with authConfig.accountDeletion on the operator auth config route.

From the browser

An access token on its own is not enough to delete an account from the browser. Anyone who has stolen a token could otherwise destroy the account with it. So a call with the publishable key must carry a second proof: the account's current password, or a code from the authenticator app (or an unused backup code) when MFA is enrolled. With the React SDK:

import { RekeyBrowserClient, RekeyError } from "@rekey.dev/react";

const client = new RekeyBrowserClient({ apiUrl, publishableKey: "pk_live_…" });

try {
  await client.deleteAccount(accessToken, { password });
  // The account is gone, and so is the session. Send the user home.
} catch (err) {
  if (err instanceof RekeyError) showError(err.code, err.message);
}

A wrong or missing proof answers 401 STEP_UP_REQUIRED. Password attempts here count toward the same lockout as sign-in, so a stolen session is not a second place to guess the password. An account with no password and no MFA, such as one that only ever signed in with Google, has nothing to confirm with and gets 400 STEP_UP_UNAVAILABLE. Ask that user to set a password or enroll MFA first, or delete the account from your server.

From your server

With a secret key, your backend is the gate and the call needs no password or code. The key needs the auth:write scope. With the Node SDK:

import { Rekey } from "@rekey.dev/node";

const rekey = new Rekey({ apiUrl: process.env.REKEY_URL!, secretKey: process.env.REKEY_SECRET! });

const { erasedAt } = await rekey.auth.deleteCurrentUser(accessToken);

This is the path for server_only: confirm however suits your product, then call it with the user's access token. Both SDK methods resolve to { erased: true, erasedAt }.

When it is refused

The subscription rule is there so nobody keeps getting charged after their account is gone. Rekey does not cancel the subscription for the user. That stays a separate, visible step, with client.cancelSubscription(accessToken) in the browser or rekey.billing.cancelSubscription(accessToken) on your server. A subscription you granted by hand, with no payment provider behind it, does not block deletion.

What erasure removes and keeps

The call runs the same erasure as the panel's Erase (GDPR) button. It cannot be undone.

• Every session ends. Sign-in methods are deleted: the password, linked OAuth identities, MFA, passkeys and any outstanding magic or reset links.
• The email becomes a placeholder address and metadata is cleared, so the real address is free for a new sign-up.
• Payments, subscriptions and licences stay as the financial record, with their free-form metadata scrubbed.
• The user.erased webhook fires, so you can remove your own copies of the user's data.
• The tombstone records the user's own id in erasedBy, and the end_user.erased security event names the end user as the actor.

The full list, model by model, is in docs/data-erasure.md.

Where to go next

1. Pick the accountDeletion value under Application → Auth before you add the button.
2. Handle user.erased in your backend, the same way you handle the webhooks in sending new users to onboarding.