Data retention policy
Policy version 1.0 — effective September 3, 2026
This page states what the platform actually retains and what it actually deletes, category by category, using the names of the storage models in the production data schema. Where automated deletion does not exist yet, we say so plainly instead of describing a purge that is not implemented. These are operating commitments and policy targets, not audit outcomes.
Retention by data category
| Data category | Stored in | Retention policy | Automated deletion today |
|---|---|---|---|
| Conversations and messages | Conversation, Message, Ticket | Retained for the life of the workspace. Conversations that are resolved or closed and inactive for more than 90 days are archived (their status is set to closed) by the daily cleanup job; archival is a status change that preserves the record, not a deletion. | None on a time basis. Records are removed by workspace deletion (database cascade) or by the documented privacy flows below. |
| Email channel messages | EmailMessage | Retained with the conversation for the life of the workspace, including threading headers and attachment metadata (filename, size, URL). The platform does not operate a production object store for email attachments. | None beyond the conversation-level handling above. |
| AI run traces | AnalyticsEvent records of type ai_run_trace | One trace per AI-assisted response (retrieval sources, grounding and confidence signals, quality scoring) is retained for the life of the workspace. Message content is scrubbed of sensitive patterns before LLM processing. | None today. Time-based deletion is a policy target, not an implemented behavior. |
| Webhook delivery and retry records | WebhookDelivery, WebhookRetryJob, BotFlowResumeJob | Deduplication, idempotency, and retry evidence for provider webhooks and workflow resumes; retained for the life of the workspace. | None. |
| Attribution events | AttributionEvent | Revenue attribution telemetry. | Implemented: automatic hard deletion after 400 days, in bounded daily batches run by the cleanup job. |
| Audit logs | AuditLog | Action trail for sensitive operations (actor, action, resource, IP address); retained for the life of the workspace. | Erasable by design: entries for the affected workspace are deleted as part of Shopify customers/redact and shop/redact privacy processing. |
| Platform operator evidence | AtlasOperatorAudit | Append-only record of platform staff operations, enforced by a database trigger; intentionally retained indefinitely as security evidence. | None, by design. This is why operator evidence is kept out of the erasable AuditLog table. |
| Security audit events | SecurityAuditLog | Integration credential lifecycle events (key fingerprints, IP address, user agent); retained for the life of the workspace. | None. |
| Dashboard sessions | Session (plus Supabase Auth sessions) | Session lifetime and sign-out are enforced by the auth provider; the Session table holds device and last-active metadata for the life of the workspace. | Session expiry is enforced by the auth provider; table rows are not auto-purged. |
| Widget telemetry | WidgetPing, VisitorSession, AnalyticsEvent | Widget heartbeats, visitor sessions, and product analytics events; retained for the life of the workspace. | Redis presence and analytics cache keys expire on TTL (presence keys after 30 seconds; stale keys are swept daily). Database rows have no automated deletion. |
| Privacy request ledger | ShopifyPrivacyRequest | Records of mandatory Shopify privacy webhook processing with hashed shop and subject identifiers. | Requests complete or fail visibly; unresolved failures remain recorded for operator review rather than being silently dropped. |
| Rate-limit buckets | PublicAiRateLimitBucket | Public AI abuse-protection counters stored as SHA-256 digests; shopper identifiers and IP addresses are never stored in plaintext. | Buckets expire with their window. |
What deletes data today
- •Attribution events are hard-deleted automatically after 400 days by the daily cleanup job, in bounded batches.
- •Shopify-mandated privacy flows are implemented and verified: customers/redact and shop/redact delete or anonymize Shopify-derived customer and shop data for the affected store, including the related erasable AuditLog entries, and data-request flows deliver a machine-readable export directly to the store owner.
- •Workspace deletion cascades: removing an organization deletes its scoped records — conversations, messages, webhook records, audit logs, and telemetry — through database cascade constraints.
Honest gaps
Time-based deletion is not implemented for every category yet. Today the following are retained for the life of the workspace and removed only through workspace deletion or the privacy flows above:
- •Archived conversations, messages, and email thread records (the 90-day job archives; it does not purge).
- •AI run traces (ai_run_trace analytics records).
- •Webhook delivery and retry records.
- •Widget telemetry database rows and security audit events.
- •Dashboard session rows (session expiry itself is enforced by the auth provider).
The policy target is to introduce time-based deletion for archived conversations and AI run telemetry. Until each change ships and is verified, this page will keep describing current behavior rather than a promised purge.
Deletion and export requests
Data subject requests that arrive through platform-mandated flows (such as Shopify's GDPR webhooks) are processed by the implemented handlers described above. Merchants who need a workspace-level export or deletion outside those flows can request it through support; requests are handled as recorded operational changes with an auditable outcome, and unresolved failures stay visible for operator review instead of being reported as silent success.
Related policies
How we respond to incidents, and who processes data on our behalf, are documented alongside this policy.