Retention and deletion
auth4.dev keeps authentication data only as long as it needs it. This page lists what is removed and when, and what happens when you delete a player.
Retention schedule
A scheduled job removes data in small batches, so removal can happen a little after the times below.
| Data | Removed |
|---|---|
| Audit events | After 30 days |
| Verification email contents | As soon as delivery finishes or expires. The delivery-status record goes after 30 days. |
| Session list entries | One day after revocation, or 30 days after the session started |
| Codes, proofs, device codes, sessions and refresh tokens | When they expire |
| Inactive guest accounts | After 30 days without activity (see below) |
| Completed deletion records | 30 days after completion |
The 30-day periods are defaults for the hosted service.
Deleting a player
Project owners can request deletion from a player's page under Users. The console asks you to confirm by typing delete.
- The player is disabled immediately: no new sign-ins, refreshes or guest upgrades.
- All sessions and refresh tokens are revoked. auth4.dev then waits six minutes, so every access token issued before the revocation has expired.
- Sessions are revoked again in case a sign-in raced the disable. Then the player's identities, consent, sessions, activity records and user record are deleted together.
Requesting deletion twice is safe and returns the same request. If a step fails, it is retried with backoff, and a request that keeps failing is held for an operator.
After deletion, auth4.dev keeps:
- a deletion record with the pseudonymous user ID, reason and timestamps, and audit events that reference the user ID. Neither contains an email address or credential, and both are removed after 30 days;
- revoked session records in short-lived session storage until their own expiry, at most 30 days. These can't be used to sign in.
Delete the player's data in your own systems too, using their sub.
Inactive guests
A guest account is deleted only when all of these are true:
- it was created more than 30 days ago and has had no recorded activity since then;
- it has only a guest identity: no email or Discord identity has been linked;
- no session could still be active or refreshing;
- no deletion is already in progress.
An upgrade in progress always wins or loses cleanly. Either the upgrade finishes first and the guest is kept, or the guest is disabled first and the upgrade is refused.