Legal document

Account Deletion

How to request deletion, what the backend actually erases, what it keeps, and the gaps that remain.

Document
Account Deletion
Policy Version
1.0
Last updated
Effective date
Pending owner approval — [OWNER/LEGAL APPROVAL REQUIRED]

Review status: This web edition is a draft prepared for owner and legal approval. It is not yet in force. Items marked [OWNER/LEGAL APPROVAL REQUIRED] are unresolved and must not be published as final.

1. Summary

You can request deletion in the app from Profile → Security → Delete account. You must be signed in and may be asked to sign in again. Deactivation is reversible and is not deletion.

This page explains what the backend actually removes and what it keeps. It replaces earlier wording that suggested push devices, notification preferences, presence settings, and all uploaded files are removed automatically; the current workflow does not do that. [OWNER/LEGAL APPROVAL REQUIRED] fix the workflow or keep this disclosure.

2. Request deletion in the app

  1. Open Profile → Security and choose Delete account.
  2. Confirm the request. Recent authentication may be required.
  3. The account is deactivated immediately and enters the deletion lifecycle. The app shows the status and the grace-period end date.
  4. During the grace period you can cancel the request and reactivate the account.

Deactivation is a separate, reversible action. It is not deletion.

3. Request deletion on the web

Web deletion request is not yet available. This static page explains the process, but it has no form, database, or staff connection. A public web request channel is required for app-store compliance and for people who cannot sign in. The approved channel, identity-verification procedure, and response time are [OWNER/LEGAL APPROVAL REQUIRED]. Do not send passwords or authentication codes through any channel.

The backend already supports a staff-side deletion request (POST /accounts/{subjectId}/deletion, permission accounts.manage, recent authentication, audited). A web request could be handled through that action after identity is verified. The operator must publish the channel and procedure before this page can be used as the external deletion route.

4. What happens after a request

  1. Immediate deactivation. The account is disabled and the state becomes DELETION_REQUESTED. Existing sessions are rejected when the account is anonymised.
  2. Grace period. The length is set by the policy accounts.deletion_grace_minutes. The backend default is 43,200 minutes (30 days); the allowed range is 1–90 days. The app shows the date. You can cancel during this period.
  3. Holds. If a hold is active, the request waits in HELD. Holds come from open service requests, open commerce obligations, or a legal hold placed by staff. If holds cannot be checked, the system treats the account as held (fail closed).
  4. Processing. After the grace period and after all holds are released, a background job moves the account through READY_FOR_ERASURE → PROCESSING → ANONYMIZED. Anonymisation cannot be undone.

The grace period is configurable, so the dates shown in the app are the authoritative dates for your request.

5. What is erased

Data removed or detached by the current anonymisation workflow
DataAction
Profile name, phone, email, profile type, specialization, referral code, country, bio, onboarding dataSet to NULL
Student details (university, student number, study year, links) and client details (organisation, interests)Rows deleted
Profile imageReleased to storage cleanup
Backend sign-in identity (email, display name)Cleared; account disabled; existing tokens rejected

6. What is retained

These records are kept and remain linked to an internal identifier with your name removed, as far as the workflow allows. They are not used to contact you.

Records retained after deletion
DataWhy it is kept
Orders, payments, refunds, vouchers, reward points, subscriptions, and finance journal entriesFinancial integrity, accounting, and legal obligations
Service requests, quotes, deliveries, revisions, disputes, and their historyService and dispute integrity, and the other party's history
Messages, attachments, reviews, and provider responsesOther participants' records, dispute history, and safety
Security audit logs, including IP address and user agentSecurity, fraud prevention, and legal obligations; append-only
Account lifecycle historyProof of the deletion request and its processing

Chat history may remain visible to the other participants, with your account shown as deleted, so their records are not silently rewritten. Reviews remain public if they were published.

7. Known deletion gaps

The following items are not removed automatically by the current workflow (reviewed 10 November 2026). This page discloses that limitation instead of promising deletion that does not happen.

  • Push-device registrations are not revoked by the anonymisation workflow. Revoke the device before deleting, or ask support; the operator must confirm what support can remove.
  • Notification preferences and presence settings are not removed.
  • Uploaded files other than the profile image are not removed automatically. Ask support; the operator must provide a removal path.
  • The Supabase Auth user record is not deleted by the backend workflow. The backend account is disabled and its tokens are rejected, but the authentication record may remain.
  • Audit logs are append-only and cannot be deleted through the application role.

These gaps are [OWNER/LEGAL APPROVAL REQUIRED] to fix or to disclose in the final published policy, and to reflect in the app's in-app legal text.

8. Timeline and backups

Deactivation is immediate. The grace period is configured (default 30 days; range 1–90 days). Final processing starts after the grace period and after any hold is released. A fixed completion target in days is [OWNER/LEGAL APPROVAL REQUIRED]; no target is published here because none has been formally approved.

Backups, where the infrastructure provider keeps them, expire according to that provider's retention and are not individually restored into the live service. The backup retention period is [OWNER/LEGAL APPROVAL REQUIRED].

9. If you cannot sign in

Use the in-app support conversation if you can still access another session or device. If you cannot sign in at all, the public web request channel described in section 3 is required; until it is approved, there is no verified public channel for this request. Do not send passwords, authentication codes, or payment card details.

10. Contact

The published support channel is the in-app support conversation (Profile → Contact support). A public deletion contact for this website is [OWNER/LEGAL APPROVAL REQUIRED].