Data retention & privacy

The exact request and response shapes are on the Data retention API reference.

The retention window

Every environment has one data-retention policy with a single window, retention_days. The default is 90 days; you can set it anywhere from 7 to 365. Read and write it with the endpoints above, or from the dashboard under Settings → Data. Sandbox and production each have their own policy and are configured independently — the environment always comes from your API key, never from the request body.

The window is measured from when a record settles — a delivered or failed message, a delivered or failed webhook event — using its creation time. Once a record is older than the window, Tyxter redacts its content on the next daily sweep. In-flight messages that a worker still needs to read are never touched until they settle.

What gets redacted, and what survives

Redaction removes content in place. It never deletes the row and never removes the record’s identity. For every settled message past the window, Tyxter nulls the message payload, its metadata, and any stored provider error, stamps redacted_at, and cascades the same removal to that message’s delivery and status events and to the webhook events that were fanned out for it.

What always survives: the record’s id, its status, its timestamps, and its trace_id — so your reporting, reconciliation, and support lookups keep working. Reading a redacted message with GET /v1/messages/{message_id} still returns 200 with the full envelope — only the content fields are blank and redacted_at is set.

A separate, fixed operational sweep trims Tyxter’s own plumbing on a platform schedule you do not configure: processed internal events are deleted after about 30 days, stored webhook delivery-attempt response bodies are blanked after about 30 days (the attempt row itself survives), and dashboard notifications are removed after about 180 days. One effect is visible to you: the GET /v1/webhook-events/listen replay feed reaches back at most a rolling ~30 days. The durable event log at GET /v1/webhook-events is not affected by that limit and follows your retention window instead.

What retention never removes

Some records are kept regardless of the window because you — or the law — need them: billing and usage ledgers, invoices, fiscal (NFS-e) documents, the contact consent ledger (opt-in and opt-out history), and audit logs. These are exempt from both sweeps.

The export switch

The second knob on the policy is data_export_enabled (default on). It gates the contact data export, POST /v1/contacts/{contact_id}/export. When you turn it off, that endpoint returns 403 data_export_disabled, and the check runs before the contact is looked up — so a blocked export never reveals whether a given contact exists. Turning it back on takes effect immediately on the next call. An environment that has never set a policy keeps export enabled.

Erasing one contact

The retention window is environment-wide. To remove a single person’s content on request — a right-to-erasure ask — delete that contact instead of waiting for the window: erasing a contact scrubs their messages and stamps redacted_at the same way the daily sweep does. The Contacts API reference covers the erasure endpoint.

Controller and processor

You are the data controller for the conversations you run through Tyxter; Tyxter is the processor that stores and delivers them on your behalf. The retention window and the export switch are the controls that let you meet your own retention and access commitments.