Data Retention & Deletion Schedule

This schedule explains how long the current SAYDO application is designed to keep different categories of information, what causes deletion, what remains after a control is used, and which provider or infrastructure limits sit outside an immediate record-by-record purge. It forms part of the Privacy Notice.

1. How to read this schedule

A “default” is the current production configuration or schema default, not an unconditional promise that every copy disappears at the same second. Automated cleanup is bounded and runs in batches. A record can be kept longer where it is still needed for an active job, payment reconciliation, fraud or security investigation, a dispute, a legal hold or another lawful purpose. Provider-controlled copies follow the provider's own controls. When an exception ends, SAYDO should delete or de-identify the record during the next applicable cleanup or review.

“Delete” can mean secure removal of the content-bearing record, cryptographic erasure by removing its encrypted payload or key-bound fields, or de-identification where the remaining transaction or security record must no longer identify the customer directly. The method depends on the record and its legal/operational purpose.

2. Current retention matrix

Information	Current automatic rule or default	Deletion trigger and candid exceptions
Local temporary voice notes, audio, images and documents	Held in a restricted private temporary directory for the processing attempt and normally removed in that attempt's cleanup step. A second bounded worker cleanup removes only recognised SAYDO per-job directories that have remained unchanged for 23 hours, processing at most 100 recognised candidate directories in one run.	The separate cleanup covers the ordinary orphan path after an unexpected process termination and drains a larger backlog over later runs. It deliberately ignores unknown names, files and symbolic links. A host outage, missed worker run, permission failure or unusually large backlog can delay removal beyond 24 hours; protected backups and provider copies follow their separate schedules.
Encrypted queued job payloads	Retained while a job is pending, processing or waiting for a bounded retry. Payload fields are cleared when the job completes, is cancelled, is rejected or reaches its terminal failure handling.	Retryable work keeps the encrypted payload so the accepted request can finish without asking the user to resend. A locked or interrupted job can be recovered until its retry/attempt boundary is reached.
Voice transcript reply context	30 days by default. The configured range is 1–90 days.	Deleted earlier by memory/history reset, linked-history deletion, consent/account workflows that purge the sender, or full account deletion. This short-lived context is separate from a transcript copied into searchable memory.
Attachment question context and OpenAI file reference	30 days by default and at most 30 days under the current configuration guard.	Expiry, history deletion or account deletion removes the local encrypted context and queues deletion of the OpenAI file. Provider deletion is retried within a bounded job process; a terminal provider failure can leave a provider-controlled copy subject to OpenAI's terms and an operational incident record.
Searchable memory records and encrypted conversation archive	365 days by default. A linked identity can be configured from 30 to 3,650 days, and the dashboard shows the applicable period. Each record has its own expiry timestamp.	Memory is on by default for newly linked numbers. MEMORY OFF, memory clearing, reset/history deletion and full account deletion purge records early. The bounded worker deletes expired records in batches. No attempt is made to recreate content that was not captured before memory/archive support existed.
Memory keyword indexes, encrypted vectors, content fingerprints and rankings	Linked to the corresponding memory record or short-lived search session.	They are deleted by database cascade when their memory record/search session is deleted. Keyed term hashes and encrypted vectors are not plain message text, but they remain personal information while linkable to a sender.
Memory search sessions	15 minutes by default for the encrypted query/selection session.	Expired sessions are removed by bounded cleanup or sooner when sender memory is purged. Completed AI memory-answer metadata can remain until its source operational message is deleted.
OpenAI conversation state	OpenAI Conversations and their items remain at the provider until SAYDO asks OpenAI to delete them or provider rules otherwise remove them.	RESET, CLEAR MEMORY, confirmed DELETE HISTORY and full account deletion invalidate the current local mapping and request provider deletion. If the provider call fails, SAYDO records a partial state and uses a bounded retry path; deletion is not falsely reported as complete while work remains.
Completed or rejected inbound operational message rows	90 days by default, removed in batches after processing.	The row holds routing/status metadata rather than the completed job's full payload. The automatic query applies specifically to completed/rejected rows; failed, exceptional or investigation-related states are not all covered by that same query and can remain longer pending operational resolution.
Outbound delivery metadata	Encrypted outbound body fields are cleared after a confirmed send or terminal failure. Failed/uncertain body fields older than the 90-day operational default are also cleared in batches.	Non-content metadata such as Meta message ID, status, purpose, size, timestamps and error code is not governed by one blanket 90-day row-deletion rule while the contact/account exists. Contact or account deletion removes linked rows through the ownership cascade.
Processing-job status and error metadata	Payload content is cleared at terminal state; job metadata remains linked to the inbound record for idempotency, restart recovery and failure visibility.	It normally disappears when its parent inbound/contact record is removed. Historical terminal failures may remain for operational evidence until resolved or a scoped retention process removes the parent record.
Usage totals and service entitlement	Monthly counters, plan state, credit buckets and credit ledger entries are retained while needed to display status, enforce allowances and reconcile account activity.	They do not currently share a single fixed automatic expiry merely because the usage month ended. Full account deletion removes active credit buckets and ledger entries. Immutable payment evidence is handled separately below.
Application and portal database audit records	365 days by default, with a configurable range of 30–3,650 days.	Cleanup removes ordinary audit rows in batches. Records subject to a security incident, fraud inquiry, legal hold or payment dispute can be copied to a separately protected case record for the lawful duration of that matter.
Portal authentication sessions	30-minute idle and 8-hour absolute lifetime by default. Revoked or expired session rows are deleted after a further seven days.	Logging out revokes the current session; password/security changes can rotate the account's session version. Account deletion removes all linked sessions immediately when the deletion transaction completes.
Password reset and invitation tokens	Reset links default to 30 minutes; administrator invitation links default to 24 hours. Token rows are deleted after they are consumed or after expiry plus the short cleanup margin.	Only token hashes are stored. Email-provider copies of the invitation/reset email follow the provider and mailbox owner's retention.
WhatsApp phone-link proof	The displayed LINK code expires after 15 minutes. Encrypted code material is cleared when consumed, expired or terminally failed; related delivery/rate-limit records have bounded cleanup.	The linked phone number and consent evidence remain for the life of the authorised service or until removal/deletion, because they are the routing and ownership boundary.
Unknown-sender onboarding protection	Keyed sender/message hashes and rate-limit events use the 90-day operational default for bounded event/sender cleanup.	These records prevent duplicate or abusive registration replies and do not store the sender's plain message content.
Account profile, linked numbers and consent records	Retained while the account or linked WhatsApp service remains active and as needed to prove consent/withdrawal and ownership.	STOP suspends service but does not delete the dashboard account or retained history. Completed full account deletion removes phone/contact mappings and direct account identity, then pseudonymises the retained portal owner row.
Never-activated public registrations and unaccepted administrator invitations	30 days without activation or qualifying activity. The worker evaluates a bounded batch. A public registration is eligible only if it remains invited, has never logged in and has no contact, billing, audit or other ownership record.	An administrator invitation is eligible only while unaccepted and never used, with no WhatsApp contact, payment-mandate acceptance, validated payment order or transaction, audit or other ownership evidence. Its one suspended phone placeholder and unused internal Trial subscription, credit bucket and grant/expiry ledger records may then be removed with it. A recent, resumed, accepted, linked, audited or financially referenced identity is preserved.
Payment orders, PayFast transactions, recurring-subscription history, refunds and reconciliation	No blanket automatic application purge currently removes validated financial evidence. It is intended to be retained for applicable accounting, tax, fraud, chargeback and dispute periods, generally at least five years where South African record-keeping law requires that period.	The exact legal period and start date for each financial record must be confirmed by the operator's South African tax/legal advisers. Account deletion cancels pending orders and active recurring authority, removes the provider token from the subscription record and pseudonymises the customer, but preserves validated transaction/ITN evidence.
Marketing-site consent and attribution in the browser	The consent choice stays in browser local storage until changed or site data is cleared. Permitted first-party campaign attribution is designed to expire after 90 days.	The user can reopen Cookie settings or clear browser storage. Google Analytics/Ads identifiers, once permitted, follow Google's retention and account configuration as well as the browser's controls.
Generated CSV/XLSX exports	Generated for the authenticated download request; SAYDO does not create a customer-facing permanent export library.	The downloaded copy remains on the user's or business's device, backups or sharing destination until that owner deletes it. SAYDO cannot erase copies outside its control.
Support email and correspondence	Retained while the request is open and for a reasonable period needed for follow-up, service quality, security, complaints or disputes.	The current application has no one automatic retention timer for every mailbox. Mail-provider retention, mailbox backup and legal-hold settings also apply.
Protected server/database backups	Access-restricted disaster-recovery copies follow hosting and internal backup rotation rather than live-table row deletion.	The current service does not expose one verified universal backup TTL or delete one customer's row from every historical archive on demand. Deleted data can persist until the relevant backup is overwritten or expires; it is not used for ordinary product access and should be re-deleted if a backup is restored.
Web server, mail, network and security logs	Application database audit logs use the 365-day default. Host-, network- and provider-managed logs follow separate restricted infrastructure schedules.	There is no single application setting that proves deletion from every infrastructure/provider log. Message content and secrets are not intended to appear in ordinary application logs, but incident evidence can be retained longer where lawfully necessary.

3. What each user control currently does

Control	Effect	What it does not do
MEMORY OFF	Stops future local memory/archive capture for the linked identity and purges its current memory records, archive, keyword/vector indexes, search sessions and pending memory-answer requests.	Does not clear the current OpenAI conversation. Send RESET to clear that context too.
RESET or CLEAR MEMORY	Purges local saved memory, archive, voice/attachment context and requests deletion of the current OpenAI conversation so the next AI exchange starts fresh.	Does not close the portal account, remove the linked number, cancel a subscription or erase required payment/security evidence.
DELETE HISTORY	Requires a time-limited exact confirmation. It suspends the sender while processing, purges local content/context, deletes the linked WhatsApp-contact history and requests provider-conversation deletion.	Does not delete the whole portal or billing identity. If provider deletion must retry, new processing stays unavailable until the workflow reaches its terminal state.
STOP	Withdraws WhatsApp-service consent, suspends the linked number and cancels eligible queued processing. Reconnection requires fresh consent and a new LINK proof.	Does not delete already retained memory, account records or payment history and does not by itself cancel a paid subscription.
Remove team number	For a business account, revokes the selected number, suspends its sender routing and cancels eligible queued work.	Does not automatically delete that number's retained business-account history. The account holder can still see it until it expires or an authorised deletion control removes it.
Delete account	Requires the current password and exact phrase. Revokes WhatsApp access, deletes sender content and mappings, requests provider deletion, cancels recurring billing, removes sessions and active credits, disables the account and pseudonymises its identity.	Does not erase validated financial records, provider/log exceptions, legal holds, protected backup copies waiting for rotation, or exports already downloaded by the customer.

4. Provider-controlled retention

Meta and WhatsApp

Messages and media travel through Meta's WhatsApp Business Platform. Meta controls delivery infrastructure, service logs, safety processing, backup and legally required retention under its applicable terms and privacy materials. Deleting SAYDO's database copy does not delete a message from the user's WhatsApp device, another recipient's device or Meta-controlled records that SAYDO cannot erase through the available business API.

OpenAI

OpenAI states that API data is not used for model training by default unless the API customer opts into data sharing. Its standard abuse-monitoring logs may retain request/response content for up to 30 days, subject to provider exceptions. OpenAI Conversations and conversation items persist until deleted. Uploaded files persist until SAYDO deletes them or another provider rule applies. SAYDO issues deletion calls for conversation/file objects in the product paths described above, but OpenAI controls final provider-side deletion, backups, legal/safety exceptions and any approved data-control configuration.

PayFast, Google, email and hosting

PayFast retains payment, fraud, recurring authority and settlement information under its financial/legal obligations. Google retains consented analytics or advertising data under the configured Google account and its policies. Email and hosting providers retain delivery, access, security and backup records under their service settings. A SAYDO deletion request removes the live application data that SAYDO controls but cannot bypass those independent duties or systems.

5. Business accounts and ownership changes

All linked numbers on a business account contribute to the business's shared pool and retained workspace. The account holder can search and export the combined history. If a staff member leaves or loses access to a number, removing the number stops future SAYDO use but keeps existing history available to the business account. The business should decide, under its own lawful retention duties, whether that history should remain until expiry or be cleared sooner. Transferring or closing a business must not transfer personal information to a new controller without a lawful basis, notice and appropriate access changes.

6. Account deletion sequence and exceptional failures

SAYDO verifies the active basic account, current password and exact deletion phrase.
It marks deletion as requested, revokes approved WhatsApp access and places linked senders into a deleting state so no new AI work is admitted.
It requests deletion of each linked OpenAI conversation and cancellation of any active, past-due or locked recurring PayFast subscription.
After provider boundaries succeed, a transaction deletes local sender content, memory, archive, context, ownership mappings, credits, saved views, sessions and authentication tokens; pending orders are cancelled and the portal identity is pseudonymised.
Validated billing evidence remains, but it no longer contains the live email, username, display name, password or linked phone mapping.

A provider timeout or rejection can stop the workflow before the final transaction. This is deliberate: the system should not tell the customer that provider deletion/cancellation succeeded when it did not. The request can be retried after investigation. A delayed PayFast notification may still be retained for reconciliation, but it cannot reactivate the closed account or grant credits.

7. Holds, complaints and disputes

SAYDO may suspend ordinary deletion of a narrowly scoped record where it must preserve evidence for a payment dispute, fraud or security investigation, court/regulator request, legal claim or another duty. The hold should identify the reason, owner, scope and review date. It must not be used to keep unrelated customer content. When the hold ends, the record returns to the applicable deletion or de-identification process.

8. Retention requests and questions

Use the dashboard and WhatsApp controls described above, or contact info@saydo.co.za. State the account email or linked number and what you want accessed, corrected, cleared or deleted, but do not email a password, verification code or full card number. SAYDO may ask for proportionate identity or authority verification before changing or disclosing records.

Where a deletion is delayed by a provider, backup, investigation or legal requirement, SAYDO should explain the category and reason as far as security and law permit. The rights and complaint channels in the Privacy Notice remain available.

9. Schedule review and known control gaps

This schedule is versioned because retention must match the deployed code and provider settings. It should be reviewed whenever a new data table, provider, export, backup process, log destination, account type or AI feature is introduced.

The current public disclosure deliberately records three boundaries that require ongoing operational/legal ownership rather than implying a control that the application does not prove:

orphan media cleanup is bounded, recognises only application-owned per-job directory names and depends on successful worker runs, so host outages, permission failures or a backlog must remain monitored;
protected backups and infrastructure/provider logs do not expose one universal application-level retention period; and
validated payment/tax evidence has no blanket automatic purge and needs a documented South African legal/tax destruction review after the applicable period.

These boundaries do not authorise indefinite retention. They identify where restricted schedules, monitoring, deletion verification and legal review must remain part of SAYDO's operating controls.