Data Retention
SubscribeFlow deletes personal data after defined periods. This page documents those periods so you can assess whether they match your own retention decision.
Status: policy defined, automated enforcement in progress
The periods below are the agreed platform policy, and setting your own is live today — what you configure is stored and shown back to you. Automated deletion itself is not yet enforcing: until it ships, data is retained beyond these periods regardless of what you set.
Set your period for the policy you actually want. It takes effect when enforcement ships, and at that point it applies to your existing data — not only to records created afterwards. Deletion you request explicitly (via the API or the preference center) works today and is unaffected.
Who decides
Under the GDPR you are the controller for your subscribers' data and SubscribeFlow is your processor. That means the retention decision is yours, not ours.
The periods below are platform defaults. They are what SubscribeFlow applies in the absence of a different instruction from you. If your retention decision differs — because of your industry, your legal advice, or your own privacy notice — you can set two of them yourself. See Setting your own periods.
Retention periods
| Data | Kept for | Counted from |
|---|---|---|
| Subscribers and their subscriptions | 24 months (you can set 6–60) | Last subscriber activity |
| Notes (contact form, feedback, admin) | Follows the subscriber period | Deleted with the subscriber |
| Send records (per-recipient) | Follows the subscriber period | Deleted with the subscriber |
| Audit log | 12 months (you can set 3–36) | Creation |
| Webhook events and deliveries | 30 days | Receipt / creation |
| Login links (magic links) | 30 days | Expiry |
| Unconfirmed sign-ups (double opt-in never completed, or a re-subscription never confirmed) | 30 days | Last action |
| Campaign statistics | Indefinitely | — |
Setting your own periods
Two of the periods above are yours to set: how long an inactive subscriber is kept, and how long the audit log is kept. The others are fixed, either because they hold operational data rather than a retention decision, or because they follow the subscriber period automatically — notes and send records are deleted together with the subscriber they belong to.
In the admin dashboard: Settings → Retention. Via the API:
curl -X PATCH https://api.subscribeflow.io/api/v1/settings/retention \
-H "Authorization: Bearer $SUBSCRIBEFLOW_API_KEY" \
-H "Content-Type: application/json" \
-d '{"subscriber_retention_months": 36}'
| Period | You can set | Default if you set nothing |
|---|---|---|
| Subscriber inactivity | 6–60 months | 24 months |
| Audit log | 3–36 months | 12 months |
Leaving a period unset is not the same as setting it to the default value: an
unset period follows the platform default, including any future change to it. To
return a period you have set back to that behaviour, send the value "default":
curl -X PATCH https://api.subscribeflow.io/api/v1/settings/retention \
-H "Authorization: Bearer $SUBSCRIBEFLOW_API_KEY" \
-H "Content-Type: application/json" \
-d '{"subscriber_retention_months": "default"}'
Omitting a field leaves it unchanged; sending "default" resets it. null is
not accepted and returns 422 — a reset has to be stated deliberately, so a client
filling unset fields with null cannot change a deletion period by accident.
A short subscriber period deletes more than you may expect
The subscriber clock only restarts on activity by the subscriber, listed below. Opening or receiving your newsletter is not activity. A subscriber who reads everything you send but never touches a link in the preference centre will be deleted once your period elapses. Six months is permitted; whether it is right for your list is your decision to make deliberately.
Changes to these periods are recorded in your audit log, with the old and new value.
What counts as activity
Your subscriber period restarts only when the subscriber themselves does something:
- Signing up — where this creates their record or reactivates one that was previously unsubscribed
- Confirming a double opt-in
- Subscribing to or unsubscribing from a topic
- Proposing a new topic
- Submitting feedback from inside their preference center
- Requesting an export of their data
It does not restart when you send them an email, when a message bounces, or when you update their record through the API. This is deliberate: if delivery reset the clock, a subscriber who never engages would be retained forever purely because you kept mailing them — which is the opposite of what storage limitation requires.
Opening the preference center is not activity
Following a login link and looking at preferences is a read — it restarts nothing. Only actually changing something does.
The same applies to feedback sent through the public contact form rather than from inside the preference center: that form does not establish who submitted it, so counting it would let anyone who knows an address keep that person's data alive indefinitely.
Why not opens and clicks?
SubscribeFlow does not track email opens or clicks, so engagement cannot be used as an activity signal. This is a privacy-by-design choice, and it means the activity definition rests on deliberate subscriber actions only.
What deletion means
Expiry results in permanent deletion. Data is removed, not anonymised or archived, and it cannot be restored. Deleting a subscriber also removes their subscriptions, notes and send records.
This matches what already happens when a subscriber exercises their right to erasure through the preference center — one behaviour, not two.
Your reporting is not affected
Campaign statistics — recipients, sends, failures — are stored as totals on the campaign itself, not recalculated from individual send records. Deleting expired send records therefore leaves your historical campaign reporting intact. What you lose once the subscriber period elapses is the per-recipient detail, not the numbers.
Keep valuable feedback outside the subscriber record
Notes submitted through feedback forms expire along with the rest of the subscriber record once the subscriber period elapses. If a bug report or feature request is worth keeping, copy it into your issue tracker rather than relying on the subscriber record to preserve it.
Billing data
Invoices and payment records are held by Stripe, our payment processor, not in SubscribeFlow's database. Statutory bookkeeping retention — ten years under Swiss law (OR Art. 958f), comparable periods elsewhere in the EU — applies to those records at Stripe.
SubscribeFlow stores only your billing email and Stripe customer and subscription references as part of your account — no invoices or payment details. No subscriber data is subject to a statutory retention obligation, so nothing overrides the periods above.
Deleting data yourself
You do not have to wait for a retention period to expire.
- A subscriber can delete their own account from the preference center, which removes all their data immediately.
- You can delete a subscriber through the API — see Subscribers.
- A subscriber can export their data from the preference center, satisfying the right to data portability.
Questions
For a data processing agreement or a record of processing activities, get in touch. For a retention period that differs from the defaults, see Setting your own periods — the subscriber and audit-log periods no longer need us. If you need a period outside the permitted range, or a different period for one of the fixed categories, get in touch.