# Data retention

Source: https://kirora.io/docs/guides/account/data-retention

See how long Kirora keeps each kind of workspace data, and choose how long transactional message content is kept.

Data retention is how long Kirora keeps each kind of data in your workspace before deleting it or removing the personal details from it. Most periods are fixed or follow your plan; the one you set yourself is how long the content of transactional messages is kept.

Go to **Settings › Workspace › Data retention** to see the fixed periods and the setting. Everyone in the workspace can see the page; only admins and the owner can change the setting.

## What's kept until you delete it

Contacts and their consent, lists, segments, templates, campaigns, journeys and forms have no expiry period: they stay until you delete them. The exception is existing-customer consent for contacts in Canada, which lapses two years after it was last stated; see [Manage contacts](https://kirora.io/docs/guides/contacts/manage-contacts). Campaign and journey totals and your reports stay too, even after the messages behind them are anonymised.

## Your plan's history period

Sent messages follow your workspace's **history period**, which depends on the owner's plan: from 90 days on Free to two years on Growth. Tracked events and the audit log each have their own period: events are kept for 30 days on Free and a year on paid plans, and audit log entries from 30 days on Free to two years on Enterprise. [Pricing](https://kirora.io/pricing) lists each plan's periods.

- **Events** are deleted when their period ends, counted from when each event happened. The period is set when an event is stored, so a plan change applies to new events only. Segment rules, conversion goals and Goals look back no further than the events that are kept.
- **Sent messages** older than the history period are anonymised, not deleted: the link to the contact, the address, the content and the provider's details are removed, and the message keeps its status and dates. Campaign and journey totals stay correct, but an anonymised message no longer counts towards a segment rule about who opened or clicked.
- **Audit log** entries older than the audit period are deleted. See [Audit log](https://kirora.io/docs/guides/account/audit-log).

For 30 days after a plan change, no messages or audit log entries are removed under the new plan's periods, so moving to a smaller plan doesn't take your history away the same day. The fixed periods below still apply.

## Fixed periods

| Data | Kept for |
| --- | --- |
| Form submissions | 1 year. The consent a signup recorded stays with the contact |
| API request log | 31 days |
| Webhook deliveries | 30 days, or 90 days if the delivery failed, so you can resend it |
| Notifications in the bell | 90 days. Emailed ones stay in your inbox |
| Kiro AI conversations | 90 days after the last message. A conversation still in use is kept |
| Contact exports and message exports | 7 days. Export again to get a new file |
| A segment's daily size | 400 days |

Removal runs in the background, so data can stay readable for a short while after its period ends.

## Transactional message content

A transactional message's content is what a receipt, login code or other one-to-one email said, readable from its delivery record. Kirora keeps it for 30 days by default, so your team can check what a customer received.

To change the period:

1. Go to **Settings › Workspace › Data retention**.
2. Under **Transactional message content**, enter a number of days from 0 to 90 in **Keep it for**. 0 keeps content only until the message is sent.
3. Choose **Save**.

A shorter period also applies to content you already have. Kirora asks you to confirm with **Delete older content**, then deletes the older content at once. It can't be recovered.

Some content is kept only while the message waits to be sent, whatever the setting:

- A message your developer sends with `sensitive: true`. Its content is stored while the message is queued or sending, including until a scheduled send time, and removed as soon as it's sent, fails or is skipped. Your team can't read it afterwards. Use it for password resets, verification codes and anything else secret.
- Attachments, which are deleted once the email is sent, or once it won't be.

The delivery record itself, with its status and dates, follows the history period above. Developers can find the details in [Retention and deletion](https://kirora.io/docs/api/retention) and [Transactional email](https://kirora.io/docs/api/transactional).

## Deleting contacts and workspaces

- **A contact.** Deleting a contact removes it with its events, list memberships, consent history and journey runs, and removes the link between it and the campaign and transactional messages it was sent. An address on the suppression list stays there, so it isn't emailed again if it's imported later. A deleted contact can't be restored. For a right-to-erasure request, your developer can delete contacts through the API; see [Deleting contacts](https://kirora.io/docs/api/retention#deleting-contacts).
- **A workspace.** Everything in it is deleted for good after a grace period, 14 days by default, which the owner can cancel until then. See [Delete a workspace](https://kirora.io/docs/guides/account/workspaces#delete-a-workspace).

## Next steps

- [Audit log](https://kirora.io/docs/guides/account/audit-log): who did what, and how far back it goes
- [Retention and deletion](https://kirora.io/docs/api/retention): every period, for developers and data-protection reviews
- [Plans and billing](https://kirora.io/docs/guides/account/plans-and-billing): what each plan includes
- [Security and access](https://kirora.io/docs/guides/account/security-and-access): roles and who can change settings