Skip to content
Sudomimus

Account deletion

View as Markdown

A Sudomimus end-user can permanently delete their account at any time from the Profile page on with.sudomimus.com. This page is for application developers integrated with Sudomimus: it describes what your application observes when that happens and how to handle it gracefully.

The user-facing flow itself — including confirmation and policy text — is part of the Privacy Policy.

What your application sees

Section titled “What your application sees”

A deleted account is treated the same as a disabled account by every realize-time and refresh-time chokepoint: the difference is the error symbol and that the condition is irreversible.

WhenError you receiveHTTP / OIDC mapping
POST /redeem on ConnectAccountDeleted403 Forbidden
POST /refresh on ConnectAccountDeleted403 Forbidden
POST /direct-issue/steam-ticket on Native APIAccountDeleted403 Forbidden
POST /direct-issue/access-key on Native APIAccountDeleted403 Forbidden
POST /token (auth-code) on OIDC APIinvalid_grant — “Account is deleted”400
POST /token (refresh-token) on OIDC APIinvalid_grant — “Account is deleted”400
GET /userinfo on OIDC APIinvalid_token — “Account is deleted”401

AccountDeleted is a new error symbol introduced alongside the existing AccountDisabled. Already-issued access tokens are not retroactively invalidated — they remain syntactically valid until their exp claim, just like for the disabled case. The user is gone at the next refresh attempt, not the moment they click the button.

How to handle AccountDeleted in your app

Section titled “How to handle AccountDeleted in your app”

Treat it the same way you treat AccountDisabled today, with one difference: do not surface a “your account is suspended, contact support” UI. A deleted account is gone by user choice; the appropriate UX is to drop the local session and direct the user toward a fresh sign-up if they want one.

A simple decision tree:

/refresh fails with AccountDeleted
  │
  ▼
Clear your local access cookie / SDK state
  │
  ▼
Surface a sign-out screen
  │
  ▼
(optionally) offer "Sign up again" → starts a fresh /establish flow

What you should not do:

  • Do not retry — the symbol is terminal, not transient.
  • Do not auto-re-create an account on the user’s behalf. A new sign-up is a deliberate user action.
  • Do not assume the user’s previous data carries over. Even if they sign up again with the same email, your application sees a brand-new subject (sector subject) with no historical link to the old one.

Owning a live organization blocks deletion

Section titled “Owning a live organization blocks deletion”

Applications and sectors are owned by an organization, not by an individual, so deletion is gated at the organization level: a user cannot delete their account while they are the sole OWNER of an organization that still holds a live resource.

  • An organization blocks deletion when you are its sole OWNER and it still holds either an enabled application or a non-disabled sector. Retiring those resources clears the block.
  • A co-owned organization never blocks — another OWNER remains to manage it.
  • An organization whose resources are all already disabled never blocks; on deletion it simply becomes owner-less.

The erasure attempt fails with AccountOwnsLiveOrganizations (surfaced as HTTP 409 Conflict); the response carries the blocking organizations’ anchors so the in-product flow can list exactly what to retire.

The full path to deletion is therefore a retire-then-delete cascade: in each organization you solely own, disable every application, then disable each now-empty sector (now permitted, because their applications are all disabled), then delete the account. (You may also disable the organization itself, but that is not required for deletion.)

This is deliberate. An organization — and the applications and sectors it owns — is infrastructure that holds other people’s data, so Sudomimus will not silently destroy it as a side effect of one developer’s personal account deletion. If you solely own an organization with live resources and are thinking about closing your account, plan a retire step for it first.

Re-registration semantics

Section titled “Re-registration semantics”

A user who deletes their account and then signs up again — even with the same email address — gets a brand-new account with no historical link to the deleted one:

  • A new internal account (and therefore a new subject / sector subject for every application sector — the value your application receives changes).
  • A new EmailIdentity row (the old one was deleted, freeing the email).
  • New Authentication rows.
  • No carry-over of preferences, applications, or any session.

From your application’s perspective this is indistinguishable from a brand-new user. Your subject-keyed data store should treat the two as unrelated.

Section titled “Related”