GDPR Data Subject Request Endpoints

Owner: trust & safety team Last reviewed: 2026-07-20

Registry of per-domain endpoints that fulfil GDPR data-subject rights (Articles 15-21). This is the index trust & safety uses to respond to DSARs (data-subject-access-requests) within the 30-day statutory window.

Pair this with pii-inventory.md — that doc lists what data each domain holds; this doc lists how to read it out or delete it.

Article 15 — Right of access (export)#

Status: as of 2026-07-20, the maat, yemaya, and Oshun BFF endpoints are implemented and gated behind auth. The Oshun BFF serves completed bundle bytes from its durable export authority. The lilith async export was designed but not yet shipped (tracked separately). The aphrodite endpoint exists but the financial-export portion needs PCI review before going live.

Article 17 — Right to erasure (deletion)#

The Oshun BFF executes signed deletion fan-out only when the event bus and attestation signer are configured; otherwise the request remains scheduled and does not receive a fabricated completion receipt.

Metis BYO-material operator decisions are canonical internal, non-exportable review_package records rather than learner-visible content. Signed account erasure pseudonymizes the exact reviewing operator reference, removes that operator's free-text rationale, and retains the minimized governance record for seven years subject to legal holds and retention exceptions before physical purge. The current partition stores no authoritative source-to-learner ownership mapping, so this is not a claim that learner erasure deletes a reviewed source.

General operator-inbox decisions are also canonical internal, non-exportable review_package records. Signed account erasure pseudonymizes the exact reviewer, removes that reviewer's rationale and authored assignment, and scrubs exact assignee-value matches from adjacent records. The minimized governance record remains subject to the same seven-year legal-hold/retention-exception- aware lifecycle before physical purge. The assignee is currently a free-form display label, not an authoritative operator-directory mapping, so this does not claim broader assignee-account deletion.

The shared operator-incident lifecycle is an internal, non-exportable review_package. Signed account erasure domain-pseudonymizes exact lifecycle actors and acknowledgements, removes details authored by that operator, clears an exact current assignee match, scrubs exact assignee references in adjacent history, and persists a subject fence even when no incident matched. The minimized package remains for seven years subject to legal holds and retention exceptions; expiry replaces the retained pseudonym with a non-linkable purge marker. The six-item incident catalog and assignee labels are currently fixture-backed, so this is not an operator-directory identity or canonical external incident-ingestion claim.

Citation-drift terminal resolutions and per-source classifications are also internal, non-exportable review_package records. Before profile erasure, any durable pending terminal decision is reconciled against the exact terminal operator-incident authority. Erasure then pseudonymizes the exact reviewer, removes reviewer-authored rationale and searchable-audit correlation, and persists independent resurrection fences for both partitions. The minimized records remain for seven years subject to legal holds and retention exceptions; expiry irreversibly removes the retained pseudonym-linked rows while preserving the fence. The two snapshots and the incident ledger are ordered but are not an atomic cross-document transaction.

Customer Themis moderation appeals are exportable support_case records. The customer read API exposes a decided verdict and rationale without internal reviewer identities. Signed account erasure first replays any durable pending outcome into the internal DSA aggregate, then pseudonymizes both stores and removes appellant, statement, and verdict narrative. The Themis case remains subject to five-year retention; the DSA review_package remains subject to seven-year retention, in each case with legal-hold and retention-exception evaluation before physical purge. This ordered reconciliation does not create an atomic transaction across the two snapshot documents.

Tombstone semantics are documented in ../releases/v1/specs/v1-tombstone-semantics.md.

Article 16 — Right to rectification#

User profile rectification flows through the normal account settings UI on each domain. There's no special endpoint registry because the same write endpoints that create the data accept updates.

If a user disputes data they cannot rectify themselves (e.g., a disputed transaction or a chat-moderation decision), the trust & safety team handles it via the internal admin UI; the audit log captures the change.

Article 18 — Right to restriction of processing#

Article 20 — Right to data portability#

The Article-15 export endpoints above produce machine-readable JSON suitable for portability. Format documented in:

• libs/contracts/src/common/customer-data-export.ts — canonical export schema across domains.

Article 22 — Automated decision-making safeguards#

V1 services that use automated decision-making (moderation, recommendation):

Process#

1. DSAR received via privacy@oshun.dev (or in-product flow).
2. Trust & safety creates a Linear ticket within 1 business day.
3. Identity verified against users.email + a second factor (MFA challenge or a manual signature for high-sensitivity requests).
4. Domain-by-domain export / deletion executed via the endpoints above; ticket logs each step.
5. Bundle delivered to the user via the same channel they used to request, encrypted at rest in S3 with a per-request key (and a 7-day download link).
6. Ticket closed with timestamps; preserved in the compliance archive for 7 years.

The 30-day statutory clock pauses when waiting on user identity re-verification; otherwise it runs continuously.