Personal Data Export
Give a user everything you hold about them, safely.
What it adds
A subject-access-request flow that gathers one person's data from every table and file store, packages it, and delivers it to a verified requester.
What your agent is told to do
6
What your agent is told to do
6-
1
Enumerate every place personal data lives for a single user — profile, content, comments, activity, sessions, billing, support messages, uploaded files — and assemble the export from that list, not from whatever a list view happens to show.
-
2
Verify identity before generating and again before releasing the file. Re-authenticate, and require the account's second factor if one is enabled.
-
3
Generate asynchronously and notify the user when it is ready. A complete export can take minutes and must not run in a web request.
-
4
Package machine-readable structured data alongside a plain human-readable index that explains what each file contains.
-
5
Deliver via a single-use, short-lived, unguessable link, and delete the generated archive when it expires.
-
6
Do NOT include other people's data. Shared threads, workspace records, and messages the user received contain third parties — include the requester's contributions and redact the rest, and never include another user's email or personal fields.
Edge cases it handles
7
Edge cases it handles
7- The export archive is itself a breach vector: it is the most concentrated copy of a person's data you will ever produce. Encrypt at rest, expire fast, and never email it as an attachment.
- Jointly owned workspace data belongs to the workspace, not the individual. Decide and document what a member gets versus what an owner gets.
- Do not email the download link to an address the requester changed minutes earlier — check for a recent email change and require confirmation.
- Rate-limit requests. Repeated export generation is an easy denial-of-service and an easy way to leave copies lying around.
- Derived and inferred data counts too: computed scores, segments, and internal tags about the person belong in the export.
- Very large accounts need chunked archives or streaming; a single multi-gigabyte file will fail on download.
- Log that an export was requested, generated, and downloaded, including by whom — but do not log its contents.
Definition of done
9
Definition of done
9- The export covers every store holding the requester's personal data, per a documented data map.
- Identity is verified before generation and before download.
- Generation is asynchronous and the user is notified on completion.
- The archive contains structured data plus a readable explanation of its contents.
- Download links are single-use, expiring, and unguessable, and the archive is deleted on expiry.
- No third party's personal data appears in the export.
- Export requests are rate-limited and audit-logged.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Data Retention Controls
Data Retention Controls
Delete data you no longer need, on a schedule, instead of keeping everything forever.
What it does
Configurable retention windows per data type, with a scheduled job that deletes expired records and everything derived from them.
How it works
- 1 Build a data map first: every table, file store, log stream, search index, cache, and third-party processor that holds customer data, and how old the oldest row is.
- 2 Define a retention window per data type, not one window for the whole app. Activity logs, uploaded files, and billing records have different obligations.
- 3 Run deletion as a scheduled, idempotent, batched job that can be stopped and resumed, and that records what it deleted in an audit trail.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/data-retention-controls
Data Anonymization
Data Anonymization
Strip identity out of old records without wrecking your reporting.
What it does
An irreversible scrub of identifying fields across the schema that keeps rows, relationships, and aggregate counts intact.
How it works
- 1 Classify every column as identifying, quasi-identifying, or non-identifying. Free-text notes and file names carry identity too and are the ones teams forget.
- 2 Replace identifying values in place rather than deleting rows, so foreign keys stay valid and historical counts do not change.
- 3 Make the replacement irreversible: random or tokenized values with no stored mapping back to the original. If a lookup table exists, this is pseudonymization, not anonymization — call it that.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/data-anonymization
Consent and Cookie Preferences
Consent and Cookie Preferences
Let users decide about optional tracking before the scripts load.
What it does
A consent layer that blocks non-essential scripts and storage until the user allows them, and records the choice as proof.
How it works
- 1 Inventory every script, pixel, embed, and cookie the app sets, and classify each as strictly necessary, functional, analytics, or marketing.
- 2 Block non-essential categories from loading at all until consent exists. Loading a tracker and then asking is not consent.
- 3 Store the choice with a version, timestamp, and how it was given, so a later policy change can re-prompt only the people it affects.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/consent-and-cookie-preferences
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.