Privacy & data controls
Everything you need to exercise your own data rights, and the tools your Recipients have for theirs, lives under Settings → Privacy & data and the hosted pages MailInApp emails on your behalf. Nothing here requires emailing support first.
Exporting your account data
Click Export my data to download a single JSON file covering every collection your account owns — projects, contacts and other data sources, tickets, mail threads, sends, schedules, orders, webhook history, team members, and your settings. Credentials are masked the same way they are everywhere else in the dashboard (an SMTP password or webhook secret never appears in the export any more than it appears in an API response). This is owner-only: an editor can build and send, but the underlying data isn't theirs to walk off with.
Deleting your account
Click Delete account, confirm the warning, and MailInApp emails a confirmation link to your account email (or shows it directly if the email can't be sent). The link expires after 24 hours and doesn't delete anything until you actually follow it and confirm — a bare click from an email preview or link scanner never triggers deletion.
Once confirmed, deletion is permanent and covers:
- Every project, contact list and data source, and their rows
- Interaction and response history, aggregates, tickets and mail threads
- Sends, schedules, orders and webhook history
- Uploaded media and inbound-mail attachments
- Your sender profile and its handle, releasing it for someone else to claim
- Your Firebase sign-in itself
Suppression records (unsubscribes and bounces) are the one exception — they're kept so a previously suppressed address stays suppressed even after the account that suppressed it is gone, the same retention reasoning covered in the Privacy Policy. This is owner-only, like export — an editor can't delete the account they work inside of.
Correcting or deleting a Recipient's data
MailInApp doesn't own a Recipient's data — the Customer who collected it does, as their contact list's controller. What MailInApp gives a Recipient is a routing mechanism, not a self-service delete: every hosted unsubscribe page (/u/[token]) includes a second form, "Correct or delete your data," below the unsubscribe link. Submitting it opens a support ticket addressed to you, badged as a Privacy request, with the request type (correction or erasure) and any details the Recipient added. Reply through your normal ticket inbox once you've made the change on your end — MailInApp has no way to know what "correct" means for a field only you understand the context of.
Why deletion isn't automatic for Recipient rows
A single click can't safely delete "this person's data" from a Customer's contact list, because doing so could silently break response attribution for every campaign that recipient interacted with, void an order's audit trail, or ignore a legal reason the Customer has to retain the record (an unresolved dispute, a completed transaction). That decision has to stay with the controller — routing it as a ticket puts it in front of the one person positioned to make it correctly.