Data Retention Schedule
Last updated 4 July 2026
This page sets out how long outr keeps each category of personal and operational data, where it is stored, and the period or event that triggers deletion. Read it alongside our Privacy Policy, our Data Processing Addendum, and our Sub-processor List.
1. How to read this schedule
- Data category names the records concerned.
- Where stored identifies the primary store. Most application data sits in our hosting and database provider; some is also held by the relevant provider that helps run part of the service.
- Retention period or trigger is either a fixed period or the event that deletes or neutralizes the data.
- Status describes what is actually built today, so nothing here is aspirational.
"Deletion on account deletion" means the in-product delete function described in Section 4, which cascades across the account's records and is permanent.
2. Account-holder data
| Data category | Where stored | Retention period or trigger | Status |
|---|---|---|---|
| Profile (email, payment-provider customer identifier, timestamps) | Our hosting and database provider | Deleted on account deletion (cascade) | Implemented |
| Subscription records (subscription and customer identifiers, status, price, period dates, cancellation and lapse flags) | Our hosting and database provider; our payment processor | Deleted from our database on account deletion; our payment processor keeps its own billing and transaction records for its own legal and accounting periods | Implemented (our side); provider residual per its terms |
| Business context (company, offer, value propositions, ICP, tone, signature, constraints, facts, website, sender name) | Our hosting and database provider | Deleted on account deletion (cascade) | Implemented |
| Agent memory, agent tasks, and chat messages (your instructions, requests, and agent chat transcript) | Our hosting and database provider | Deleted on account deletion (cascade); individual agent-memory notes can be deleted at any time with the memory-forget function | Implemented |
| Credit ledger and usage events (credits, leads added, emails committed, sourced leads) | Our hosting and database provider | Deleted on account deletion (cascade) | Implemented |
| Authentication record and hashed password | Our authentication provider | Deleted on account deletion; deleting it triggers the cascade above | Implemented |
| Payment card data | Our payment processor only | Never stored by us (no card number, expiry, or security code); held by our payment processor under its terms | Implemented |
| Signup and rate-limiting IP addresses and user agent | In memory only (not persisted) | Held briefly in memory for rate limiting; not written to the database today | Implemented. Note: a future consent-record feature is planned to persist the signup IP and user agent as proof of consent; when it ships it will be kept for 24 months from collection |
3. Lead and recipient data
| Data category | Where stored | Retention period or trigger | Status |
|---|---|---|---|
| Leads (business email, name, title, company, LinkedIn URL, country, status, score, source, sourcing-run identifier) | Our hosting and database provider; our email-sending provider (for launched campaigns) | Kept in our database for the life of the account and deleted on account deletion (cascade). Our email-sending provider keeps its own copy after our deletion (see Section 6) | Implemented (our side) |
| Inbox messages and reply content (lead email and name, subject, body, preview, category, read and answered timestamps, and the full sending-provider webhook payload) | Our hosting and database provider; our email-sending provider | Kept for the life of the account and deleted on account deletion (cascade). Our email-sending provider keeps its own copy | Implemented (our side). The stored full webhook payload is broader than strictly needed and is under review for minimization |
| Campaigns (name, status, audience, sequence draft and sent copy, metrics, inbox and provider identifiers) | Our hosting and database provider; our email-sending provider | Kept for the life of the account and deleted from our database on account deletion (cascade); our email-sending provider keeps its own campaign record | Implemented (our side); provider residual per its terms |
Leads and campaign or sending history are kept for the life of the account, because they are the operating record of your outreach, and are deleted when you delete your account. There is no separate per-lead or per-reply erasure function today; requests of that kind are handled by hand, as described in Section 9.
4. Deletion flow (summary)
Account deletion is fully built and permanent. When you delete your account, we snapshot your campaigns and inboxes, pause all campaigns (aborting if any cannot be paused), detach inboxes from campaigns (aborting on failure), cancel all subscriptions (aborting on failure), release the inboxes, keep the inbox-scrub ledger by removing the account link from those rows so the scrub can still neutralize the inboxes, and then delete your authentication record. Deleting that record cascades and removes your profile, subscriptions, business context, agent memory, campaigns, leads, agent tasks, credit ledger, sending-account records, inbox messages, email accounts, usage events, and chat messages. The deletion is audit-logged. It is permanent and cannot be undone.
5. Inbox reuse and scrub
On lapse, cancellation, or deletion, inboxes are released. A daily scrub detaches them from all campaigns and resets the sender display name to a neutral value. The part of the address before the @ cannot be changed, which is a limit of our email-sending provider. Pooled inboxes become claimable again by other customers only after the scrub; dedicated inboxes are cancelled at our inbox-provisioning provider and are never reused.
6. Provider residual copies
Deleting your account removes data from our systems, but some providers keep their own copies:
- Our email-sending provider keeps its own record of campaigns and lead lists on its side after our deletion. If you need this deleted, you may have to ask that provider directly; email us at support@tryoutr.io and we will help you submit and follow up on the request.
- Our payment processor keeps billing and transaction records for its own legal and accounting periods.
- Our error-monitoring provider, where enabled, may hold error payloads that can contain limited identifiers, kept for its own configured period.
- Other providers keep data only as long as they need it to do their job and per their own terms.
Provider residual retention is governed by each provider's terms and is identified in our Sub-processor List.
7. Backups
Personal data may live on in routine, encrypted backups kept by our database and hosting providers for a limited period after it is deleted from the live system, until those backups are rotated and overwritten in the ordinary course. Backups are not used to restore data that was deliberately deleted, except as part of disaster recovery.
| Data category | Where stored | Retention period or trigger | Status |
|---|---|---|---|
| Database backups (may contain personal data pending rotation) | Our hosting and database provider's managed backups | Kept for up to 30 days on the provider's ordinary rotation cycle, then overwritten; not restored to recover deliberately deleted data except for disaster recovery | Managed by providers |
8. Operational and security logs
These records are service-role only and, in general, do not identify an account holder. Where a record carries no account link, it may survive account deletion. Each category below has a defined retention window.
| Data category | Where stored | Retention period or trigger | Status |
|---|---|---|---|
| Audit log (trail of destructive and money-moving actions) | Our hosting and database provider | Kept for 12 months from the event, then pruned; survives account deletion within that window | Implemented as policy; automated pruning rolling out |
| System errors | Our hosting and database provider | Kept for 12 months from the event, then pruned | Implemented as policy; automated pruning rolling out |
| Cron-run records | Our hosting and database provider | Kept for 12 months from the run, then pruned | Implemented as policy; automated pruning rolling out |
| Business snapshots (aggregate revenue and client counts, no account link) | Our hosting and database provider | Kept for 24 months from creation, then pruned; survives account deletion within that window | Implemented as policy; automated pruning rolling out |
| Inbox-health snapshots (no account link) | Our hosting and database provider | Kept for 12 months from creation, then pruned; survives account deletion within that window | Implemented as policy; automated pruning rolling out |
| AI call log (model, tier, tokens, latency, source) | Our hosting and database provider | Kept for 12 months from the call, then pruned | Implemented as policy; automated pruning rolling out |
| Inbox-scrub ledger rows (account link removed on deletion) | Our hosting and database provider | Account link removed on deletion so the scrub can finish; rows kept for 12 months after scrub completion, then pruned | Implemented as policy; automated pruning rolling out |
Aggregate business metrics are kept for 24 months. Operational and security logs (the audit log, system errors, and cron-run records) and inbox health history are kept for 12 months.
9. Data-subject request tooling (current limitation)
A full account-deletion function and a memory-forget function exist and work as described above. There is no per-lead or per-reply erasure function and no self-serve export function yet. Requests that need lead-level or reply-level access, erasure, or export are handled by hand by our team, following our internal privacy-request procedure, across the stores listed here, together with any follow-up needed with our email-sending provider. Building these tools is a tracked action.
10. Contact
Questions about retention, or a request relating to your data, go to support@tryoutr.io.
Questions about this page? Email support@tryoutr.io.