Skip to main content
View as Markdown

GDPR & Privacy

Sovrium gives end users self-service control over their personal data, satisfying the core GDPR rights without operator intervention. An authenticated user can download a complete, machine-readable copy of everything Sovrium holds about them, and can schedule an irreversible erasure of their account on a safe, reversible-until-final timeline.

These are end-user endpoints — they act on the caller's own data, scoped exclusively by the authenticated session. No id is ever taken from the request body.

Data Export (Articles 15 & 20)

GET /api/account/export returns the caller's complete personal-data footprint as structured JSON, satisfying the GDPR right of access (Art. 15) and right to data portability (Art. 20).

code
GET /api/account/export
Cookie: <session cookie>

No request body, query, or path parameters — the user id comes only from the session. The response aggregates four sources for the caller:

Source Contents
Profile The caller's auth.user row.
Sessions The caller's auth.session rows.
Linked accounts The caller's auth.account rows (OAuth providers + email/password credential), with all secret material omitted.
Authored records Every table record across the app where created_by = caller.

Account Deletion & Erasure (Article 17)

POST /api/account/delete lets a user request irreversible erasure of their account, satisfying the GDPR right to erasure (Art. 17). Deletion follows a scheduled-erasure model with a 7-day grace period — never an immediate destroy.

code
POST /api/account/delete
Cookie: <session cookie>
Content-Type: application/json

{ "confirm": true }
Step Request Effect
1. Schedule { "confirm": true } Marks scheduledErasureAt = now + 7 days, revokes all of the caller's sessions (logged out everywhere), writes an account.deletion.scheduled audit event, returns 202 Accepted. Does not delete yet.
2. Cancel { "cancel": true } During the window, the user signs back in and cancels — clears scheduledErasureAt, returns 200 OK.
3. Purge (automatic, after window) A purge job hard-deletes the caller's auth.user, auth.session, auth.account, auth.verification rows and every table record where created_by = caller, then writes an account.deletion.purged audit event.

A bare POST with no confirm/cancel flag is rejected 400 (anti-fat-finger).

Hard Delete, Not Soft Delete

Erasure performs physical row removal — not the soft-delete deleted_at tombstone used elsewhere in the platform. After the purge, no recoverable personal data remains, as Art. 17 requires.

This is the deliberate exception to Sovrium's soft-delete-by-default posture: ordinary deletes are recoverable tombstones, but a GDPR erasure must leave nothing behind. Per-table irreversible deletes via the admin dashboard require the explicit allowForceDelete: true opt-in (see Table Permissions); the force-delete endpoint returns 404 when force-delete is not allowed.

Privacy by Design

Beyond the self-service rights, privacy is built into the platform defaults:

  • Cookie-free analytics — visitors are identified by server-side SHA-256 hashes; no PII or client identifier is stored, and Do Not Track is respected. See Analytics.
  • Bounded retention — soft-deleted rows age out per ECO_RETENTION_PURGE_DAYS (see Ecoconception); less stored data is both a privacy and a frugality win.
  • No external services — all personal data stays on your server; nothing is shipped to a third party.

Last updated August 11, 2026

This documentation was written with AI, so errors or outdated content are possible. Sovrium is in beta. Contributions and corrections are welcome.

Built with Sovrium