Deleting your account removes the account and tears down the workspaces only you own. Read the preview first: it names every workspace and says whether it will be deleted, left, or block the request.
Once your deletion intent is recorded there is no cancel — no button, no API,
no grace reversal. Resolve every blocked row before you confirm.
What deletion removes
One request deletes your account only — never another user's account, and never a workspace on its own. For each workspace you belong to, the preview assigns one disposition:
| Disposition | Meaning |
|---|---|
delete | You are the sole member: the workspace and everything in it — services, datastores, secrets, environment groups, registry credentials, sandboxes — is torn down |
leave | Other admins remain: you are removed and the workspace keeps running for them |
blocked | The request cannot proceed until you resolve this workspace (below) |
Beyond workspaces, deletion removes your API keys, SSH keys, notification settings, and the OAuth and device grants authorizing your agents and integrations; revokes your sign-in sessions; anonymizes your residual references in activity, audit, and session records; and finally deletes the identity itself. Details per surface are in Effects.
Preview deletion
In the dashboard, open Settings and find the account-deletion card: it shows the same three lists the API returns, and each blocked workspace links to that workspace's settings so you can fix it. Or query directly:
query {
accountDeletionPreview {
delete { id name action }
leave { id name action }
blocked { id name action }
}
}{
"delete": [{ "id": "wks_123", "name": "side-project", "action": "delete" }],
"leave": [],
"blocked": []
}The REST equivalent is GET /v1/users/deletion-preview. API keys never
appear as members: the machine identities your keys minted are excluded from
the counts, so a workspace with only you plus your keys still reads delete.
Resolve blocked workspaces
A workspace blocks deletion when you are its sole admin on a shared workspace, or when it is the instance's pinned ops workspace. Any blocked row refuses the whole request. A pinned ops workspace can never be deleted by this flow; its row only clears once you are no longer its sole member. Otherwise resolve each blocked row, then preview again:
- Promote another admin so your row becomes
leave— see Workspaces, members, & roles. - Remove the other members so you become the sole member and the row
becomes
delete. - Delete the workspace yourself if nothing in it needs to survive; the disposition then disappears with the workspace.
If you own the workspace, leaving is not available to you at all —
ownership cannot be transferred yet — so a leave row for an owned
workspace cannot execute. Remove the other members first so the row becomes
delete, or delete the workspace directly.
The request re-checks dispositions when it runs, so a workspace that became blocked after your preview still refuses rather than half-deleting.
Confirm deletion
Deletion requires a direct signed-in browser session and the exact phrase.
Type it precisely — the comparison is exact, and anything else is a 400
that names the phrase:
mutation {
deleteAccount(confirmation: "delete my account") {
state
}
}curl --fail-with-body --silent --show-error \
-H "Authorization: Bearer $BEX_TOKEN" \
-H 'Content-Type: application/json' \
-d '{"confirmation":"delete my account"}' \
-X DELETE "$BEX_API_URL/v1/users"Machine API keys, OAuth client credentials, and delegated tokens are refused
with 403: this verb never runs from automation, only from you in a browser
session. A recorded request answers 202 with the deletion state
(pending for a fresh intent).
What happens next
Deletion runs asynchronously in the background: auth material goes first,
then each workspace is torn down or left per the recorded plan, then your
subject rows are removed or anonymized, and the sign-in identity is deleted
last. The state moves pending → cleaning → identity → done; a
failed step is recorded and retried rather than dropped. There is no cancel
once the intent is recorded.
Effects on keys, sessions, and billing
- API keys are deleted, including the machine identities they minted.
- SSH keys are deleted with the account.
- Agents and integrations lose access: OAuth and device grants are revoked, and CLI telemetry tied to you is removed.
- Sessions are revoked before the identity is deleted, so tokens minted afterwards fail closed.
- Billing linkage is removed with each deleted workspace: the workspace's subscription is cancelled where Stripe is enabled. This guide makes no promise about refunds, invoice history, or data exports — settle those before you confirm.
Source pin: Bex 6f2975248.