Privacy requests

Two things a privacy notice promises and most products never build: a copy of what you hold, and deletion. Both have endpoints here, and both come in two shapes — one the person can use themselves, and one for answering a request that arrived by email from somebody who cannot sign in. That second case is most of them, because people who ask to be forgotten have usually already stopped using the product.

A copy of everything

// The person, with their own session.
const data = await client.auth.privacy.export(sessionToken);

# You, on their behalf.
GET /v1/users/{userId}/data
Authorization: Bearer b316_sk_…

<PrivacyControls /> in @base316/react is the download-and-delete pair ready to drop into an account page. In the dashboard it is Export data on the user's Security panel, which hands you a file.

The export carries the account, its sessions, the security log, passkeys, linked social accounts, second factors, tenant memberships and identity checks.

What it will not hand over

Credential material — password hashes, authenticator secrets, session digests, unspent reset tokens.

These are not the person's data in any useful sense. They are the things that authenticate them, and handing them to whoever passed an identity check weakens the account rather than informing its owner.

The export says it is holding them back, and what they are, in a withheld list. Silently omitting them would be the worse answer: somebody is entitled to know what is held about them, which is not the same as being handed the keys to their own account.

Forgetting somebody

await client.auth.privacy.erase(sessionToken);

DELETE /v1/users/{userId}
Authorization: Bearer b316_sk_…

This removes the account and everything that hangs off it: credentials, password history, second factors, passkeys, sessions, verification tokens, linked social accounts, refresh tokens, memberships, identity checks, unspent authorization codes and approved device sign-ins.

What survives, and why

The response is a receipt, and it is the point of the return value rather than a courtesy. Keep it. Answering a regulator months later from memory is how a truthful process stops being one.

Invoices are kept. Tax law requires them for years after they are raised, and GDPR Article 17(3)(b) exempts data held to meet a legal obligation. Deleting them to satisfy a data subject would break a different law. The tenant they hang from is stripped of names and addresses instead, so the records stay auditable without staying personal.

Only a tenant the person was the last member of. A signup makes a tenant of one, and stripping that is right. A tenant they were invited into, or provisioned into over SSO, belongs to other people — so it keeps its name and its billing contact, and only the membership goes. Erasing yourself out of your employer's account must not rename your employer.

The security log is kept, with the person detached. The trail of a break-in is not the intruder's to erase, and with no user attached it is no longer about an identifiable person.

The receipt names both, with the reason that outranked the request:

{
	"erasedAt": "2026-09-16T12:00:00.000Z",
	"erased": ["RuntimeUser", "RuntimeCredential", "..."],
	"retained": [{ "model": "Invoice", "count": 7, "because": "Tax law requires invoices…" }],
	"anonymised": [{ "model": "RuntimeAuthEvent", "count": 214, "because": "A security trail…" }]
}

Erasure is not deprovisioning

If a directory removes somebody, that is a SCIM deactivation — the account is disabled and the record stays, because an offboarded employee is something an enterprise still needs to be able to account for.

Erasure is a person exercising a right over their own data. The two look similar from the outside and mean entirely different things; do not wire one to the other.