Geniffy Users API

openapi: 3.2.0
info:
  title: Genify Backend Users API
  version: 0.1.0
tags:
- name: Users
paths:
  /api/users/delete-account:
    delete:
      tags:
      - Users
      summary: Delete User Account
      description: 'Permanently delete user account and ALL associated data.


        GDPR Article 17 "Right to Erasure" compliant.

        Covers: the Cognito sign-in account, PostgreSQL (all tables), S3, vectors and the memory service, and sends

        a confirmation email.


        Order of operations. Two things about it changed after this endpoint was found

        to be returning success while deleting no vectors at all:


        1. Capture user info (email, uid) before anything is deleted

        2. LOCK the sign-in account (disable + sign out everywhere). This is what the old

        step 2 was actually for — stopping a re-login mid-cleanup — and it does

        that without destroying the identity we may still need. Deleting the

        identity first meant a failed data step could never be retried and left

        no authenticated way back in.

        3. Erase vectors THROUGH THE REGISTRY (app/privacy/erasure.py), which

        deletes and then counts. The old step here imported app.second_brain, a

        package with zero tracked files, swallowed the ModuleNotFoundError, and

        never touched the collection the memory actually lives in.

        4. Delete all PostgreSQL data (100+ tables + user row)

        5. Delete S3 files (uploads, recordings)

        7. DELETE the sign-in account, last, once the data is gone

        9. Send confirmation email, log audit record

        10. Answer honestly. The response used to be a hardcoded {"success": True}

        sitting directly under a correctly-computed deletion_report["success"]

        that nothing read.


        Vectors are erased BEFORE Postgres on purpose: if the user row goes first and

        the vector purge then fails, the leftovers are orphaned with nothing left to

        tie them to. The uid is logged at ERROR level in that case so a purge can be

        re-run by hand.'
      operationId: delete_user_account_api_users_delete_account_delete
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
      security:
      - HTTPBearer: []
components:
  securitySchemes:
    HTTPBearer:
      type: http
      scheme: bearer