Skip to content
Sudomimus

Account deletion

View as Markdown

A Sudomimus end-user can permanently delete their account at any time from the Privacy view 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.

When Error you receive HTTP / OIDC mapping
POST /redeem on Connect AccountDeleted 403 Forbidden
POST /refresh on Session API AccountDeleted 403 Forbidden
POST /direct-issue/steam-ticket on Native API AccountDeleted 403 Forbidden
POST /direct-issue/access-key on Native API AccountDeleted 403 Forbidden
Session GET /userinfo or GET /claim-state invalid_token 401 Unauthorized
Session POST /introspect status: "revoked" 200 OK
POST /token (auth-code) on OIDC API invalid_grant — “Account is deleted” 400
POST /token (refresh-token) on OIDC API invalid_grant — “Account is deleted” 400
GET /userinfo on OIDC API invalid_token — “Account is deleted” 401

AccountDeleted is the permanent counterpart to AccountDisabled. An already-issued access token can still pass offline signature and expiry checks until its exp, but live Sudomimus endpoints reject it or report the session as revoked. Applications should end the local session as soon as any of these responses is observed.

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 handling flow:

flowchart TD
    Deleted["POST /refresh fails<br/>AccountDeleted"] --> Clear["Clear the local access cookie<br/>and SDK state"]
    Clear --> SignedOut["Surface a signed-out screen"]
    SignedOut -. optional .-> SignUp["Offer Sign up again<br/>Start a fresh POST /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. A user cannot delete their account while they are the only active OWNER of an organization that still holds a live resource.

  • An organization blocks deletion when you are its only active OWNER and it still holds either an enabled application or a non-disabled sector. Retiring those resources clears the block.
  • A co-owned organization does not block deletion when another active 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 signs up again after deletion gets a brand-new account, even if they use the same email address. Applications receive new sector subjects, and Sudomimus does not carry over preferences, sign-in methods, grants, or sessions.

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”