Legal & policies
Data Retention & Deletion
Effective date: 9 June 2026
This policy describes how long Tradie Texts keeps personal information and how access, correction, deletion and de-identification requests are handled. It supports APP 11, APP 12 and APP 13.
1. Retention principles
We keep personal information only for as long as reasonably needed to provide the Service, support Customers, maintain security, meet legal obligations, resolve disputes and keep required business records. When information is no longer needed, we take reasonable steps to delete it or de-identify it unless we are required or permitted by law to keep it.
2. Retention schedule
| Data category | Examples | Target retention |
|---|---|---|
| Caller leads and lead metadata | phone number, job type, suburb/address, urgency, status, AI summary | Up to 24 months after last activity, then delete or de-identify |
| SMS conversations | inbound and outbound message bodies, Twilio message SID, segments, timestamps | Up to 24 months after last message, then delete or de-identify |
| Missed-call and call-event records | call SID, status, time, number metadata | Up to 24 months unless needed for security, billing or dispute handling |
| Bookings (calendar entries) | customer name, phone number, job description, service address, booking notes, appointment date and time | Caller details de-identified once the underlying caller lead has itself been deleted under the window above and the booking has been finished for up to 24 months; the appointment itself (date, time, status) is kept as a business record |
| Support chat conversations | live chat message text, visitor name, email/mobile if given, conversation status and timestamps | Message text, visitor name and contact details cleared 30 days after the last message; the conversation record deleted after 365 days |
| Opt-out and opt-in records | STOP/START status, phone number, timestamp, business | As long as needed to honour the preference and demonstrate compliance |
| Webhook payloads | raw Twilio/Stripe webhook payloads used for audit and idempotency | Minimise; target 90 days for raw message/call payloads unless needed for a dispute, security incident or billing audit |
| Account profile and business configuration | account email, business details, routing settings, AI settings | Life of the account, then delete or de-identify unless retained for legal/business records |
| Billing and tax records | invoices, subscription IDs, payment records, usage billing records | 7 years after the relevant transaction or longer if required by law |
| Application/security logs | operational logs, error logs, access/security events | Up to 12 months, with phone numbers and message bodies redacted where practicable |
| Audit records | account changes, permission changes, important operational actions | Up to 7 years where needed for legal, security or dispute reasons |
These periods are maximum targets, not promises to keep information for the full period. We may delete or de-identify information earlier where it is no longer needed.
3. Current implementation status
A scheduled retention job now runs daily and enforces the core of this schedule automatically:
- Caller leads and their SMS conversations that have had no activity for 24 months are deleted. Deleting the lead cascades to its conversations, messages and AI jobs, so caller phone numbers, message bodies and lead details are removed together in one atomic operation.
- Raw webhook payloads (un-redacted Twilio/Stripe bodies kept for short-term idempotency and audit) are deleted after 90 days.
- Bookings (where a business uses the calendar) keep their own copy of the caller's details, so a scheduled job stays readable after the underlying lead is deleted. Once that copy passes the same 24-month window, the job blanks the caller's name, phone number, job description, service address and booking notes. The appointment is de-identified rather than deleted, so the business keeps its own job history.
- Billing and tax records (usage records, subscriptions) and the audit log are deliberately preserved, so required financial records remain intact while unnecessary caller personal information is removed.
- Support chat conversations that have gone 30 days with no new message have every message's text overwritten with a placeholder and the visitor's stored name and contact detail cleared. Only the conversation's id, status and timestamps are left alone, so the thread stays findable (as "Anonymous") in the owner's support inbox. Once a conversation has gone 365 days with no new message, the conversation record itself — and its now-scrubbed messages — is deleted outright.
The destructive logic runs server-side as a single reviewed database function (purge_expired_personal_data), invoked by an authenticated daily cron job (/api/jobs/retention). The default windows are 730 days for caller leads and for the caller details held on a booking, and 90 days for webhook payloads.
Support chat scrubbing and deletion run as a separate step in that same daily job (src/lib/domain/retention.ts), not the purge_expired_personal_data database function — implemented in application code so it ships with the app instead of waiting on a migration (this repo applies migrations by hand). The 30-day and 365-day windows are named constants in that file and can be changed without touching the database.
Remaining backlog (handled manually until built):
- Per-message de-identification of very old messages that sit on a still-active lead (rare; the lead-level purge covers the common case);
- A one-click account-closure workflow for Customers; and
- A structured, auditable request-tracking log for individual Caller access, correction and deletion requests (the process itself is now documented — see below; there is no dedicated tracking table yet, so requests are logged manually).
Individual deletion and de-identification requests outside the scheduled job are handled following the process in docs/runbooks/RUNBOOK_DATA_DELETION.md, which covers how a request comes in, how identity is verified before anything is changed, which tables are touched, and how the deletion or de-identification is performed.
4. Account deletion
When a Customer requests account deletion, we will delete or de-identify business configuration, Caller leads, conversations and related operational records unless we need to retain limited records for billing, tax, legal, security, fraud prevention, dispute resolution or compliance.
Deleting a Customer account may not immediately remove records held by third-party providers such as Twilio, Stripe, OpenAI, Supabase, Vercel or backups. We will take reasonable steps available to us to action deletion or de-identification with providers where required and practicable.
5. Caller requests
Callers should first contact the trade business they called. We will assist that business to locate, access, correct, delete or de-identify relevant records. Callers may also contact hello@tradietexts.com.au directly, and we will route or action the request as appropriate.
We may need to verify identity and confirm the relevant business before disclosing or changing records. If we refuse or limit a request, we will explain the reason where reasonable and lawful.
6. Backups and residual copies
Deleted information may remain in encrypted backups or provider logs for a limited period until those backups or logs expire. We will not actively restore deleted personal information except where required for security, business continuity, legal compliance or dispute handling.
7. Contact
Privacy and deletion enquiries: hello@tradietexts.com.au