Documentation menu

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.

Exporting or erasing one Recipient's data

Once you've decided how to answer a request, open the contact's profile (Contacts, then the contact). The account owner sees a Privacy requests card there with two actions. Both cover the person across every contact list they're in, not only the list you opened.

  • Export their data downloads one JSON file with everything this account holds about them. That includes their rows with verification, enrichment and consent records, their responses and form answers, bookings, deals, journey runs, orders, tickets and mail threads, and failed webhook deliveries that carried their details.
  • Erase this contact deletes all of that. You type their address to confirm, because it can't be undone. A few things are handled differently:
    • Kept: their unsubscribe or bounce record, so a later import can never email them again, and the privacy-request ticket itself, so you can reply to confirm.
    • Cleaned, not deleted: product-block orders keep their amounts for your financial records, with the buyer's email and shipping address removed. Send history keeps its counts with the person taken out.
    • Outside MailInApp: meetings already on your Google Calendar, and records pushed to HubSpot or Pipedrive. The result lists how many, so you can delete them there.

Both actions are owner-only and need a recent sign-in, and each one is recorded in your data-access log. Nothing runs automatically: the request still reaches you as a ticket, and erasing is your decision as the controller.