Account Deletion

What the stores require

• Apple (App Review Guideline 5.1.1(v)): an app where people can create an account must let them start deleting it inside the app.
• Google Play: the same inside the app, and also a web link where people can ask for deletion without the app. You give that link in the Play Console's Data safety form.
• Both expect the person's data to go with the account, including what they created.

Koolbase covers all three: an in-app action, a hosted page for the web link, and a setting on each collection for the data.

In the app

In the Designer, give a button the Delete account action, and make it the Then of a Confirm first, with Cannot be undone on. Checks warns when it isn't behind a Confirm, and when a collection hasn't said what happens to the person's records. In code, call the SDK:

await Koolbase.auth.deleteAccount();
// The person is signed out: take them to your sign-in screen.

await Koolbase.auth.deleteAccount();

Deleting an account does this, in order:

1. Each collection's on_user_deleted setting is applied to the person's records, then each bucket's to the files they uploaded.
2. Their sessions and their account are removed, together.
3. Their Sign in with Apple token, if Koolbase holds one, is queued for revocation at Apple (see below).
4. The auth.user.deleted trigger fires, for anything else your app cleans up in a Function.

The account deletion page

Every project has a hosted page where people delete their account without the app, in your app's name, logo and colour. Copy its address from the dashboard: Auth settings → Account deletion page. That is the link to give Google Play.

https://<your API host>/v1/sdk/auth/delete-account?project=<project id>

1. The person enters their email. The page answers the same whether or not an account exists, so nobody can use it to check which addresses have accounts.
2. They enter the code from the email. The email says plainly that it is for deleting the account, so a request the owner didn't make doesn't go unseen. The code works once, for 10 minutes, and can't be used to sign in.
3. If they use two-step sign-in, they also enter the code from their authenticator app, or a recovery code. The field is always shown, so the page never says which accounts use two-step. Leaving it empty uses the emailed code up, and the page asks them to get a new one.
4. The account is deleted exactly as from the app, and the page says so.

• An account without an email, signed up with a phone number, can't be confirmed on the page: it asks them to delete it in the app, and shows your Reply-To address when you've set one in Email Branding.
• The email's wording is yours to change in Email Branding, under Account deletion code.

Sign in with Apple

Apple asks apps that offer Sign in with Apple to revoke a person's Apple tokens when they delete their account. Koolbase does it for you, once your project has its Apple key:

1. In your Apple developer account, under Certificates, Identifiers & Profiles, then Keys, create a key with Sign in with Apple ticked, and download its .p8 file. Apple lets you download it once.
2. In the dashboard, open OAuth providers → Sign in with Apple. Fill in the Team ID, and under Key for revoking tokens enter the Key ID and paste or choose the .p8 file. The key is stored encrypted and never shown again.
3. Apps send Apple's authorization code when people sign in. Apps exported from the Designer already do. In code, pass it yourself:

await Koolbase.auth.signInWithApple(
  identityToken: credential.identityToken!,
  nonce: rawNonce,
  authorizationCode: credential.authorizationCode,
);

await Koolbase.auth.signInWithApple({
  identityToken,
  nonce,
  authorizationCode, // from the Apple credential
  // client: 'web', when the code came from Apple's web sign-in
});

At sign-in, Koolbase exchanges the code for Apple's token and keeps it encrypted. When the account is deleted, the token is revoked at Apple in the background, so Apple being slow or down never stops a deletion; a revocation that fails is tried again for about 17 hours. The dashboard shows any that still failed, next to the key.

What happens to their data

Each collection decides, in the dashboard (Database → the collection → Edit → When a user deletes their account) or with on_user_deleted:

• delete: their records are deleted for good.
• remove_owner: the records stay, with their content, but no longer name them. For records that belong to the business, like a shop's sales.
• keep: the records stay as they are.
• Not chosen: kept, and shown as a warning until you choose.

The details, including append-only collections and owner fields, are in Access rules. Apps made by whole-app generation set delete on every collection.

Files work the same way. Each bucket decides, in the dashboard (Storage → the bucket → When a user deletes their account) or with on_user_deleted:

• delete: the files they uploaded are deleted for good, with every earlier version. Only theirs: a version someone else uploaded at the same path stays.
• keep: the files stay; the link to the deleted account goes with it.
• Not chosen: kept, and shown as a warning until you choose.

A record that pointed at a deleted file then points at nothing, as when any file is deleted. A profile photo is a file like any other, and follows its bucket's choice.