Retention & compliance

Messaging carries two controls your legal team will ask about — legal hold and redaction — plus a background retention worker that prunes old messaging rows on a fixed schedule. The three interact, and the interaction is not obvious: a hold blocks the reaper and blocks redaction. Beta

Public preview

Legal hold and redaction are a public-preview surface. Both endpoints are part of the published API, but their shapes may change before general availability. Treat the retention windows below as current defaults rather than a contractual guarantee.

Both actions are account-level administrative operations: the caller must be an internal actor in the target account with the right messaging permission, and they do not require membership of the conversation. Customer-portal actors are rejected outright.

Legal hold

Placing a hold preserves a conversation:

curl -X POST API_HOST/v1/messaging/conversations/cv_w35z4ck68yq7/actions/set-legal-hold \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Augno-Version: CURRENT_API_VERSION" \
  -H "Augno-Account: YOUR_ACCOUNT_ID" \
  -H "Content-Type: application/json" \
  -d '{"legal_hold": "held"}'

legal_hold takes held or released, and the action returns the updated conversation with its legal_hold field set. It requires the messaging:update permission, and the change is written to the audit trail.

While a conversation is held:

• Automatic retention purging skips it. Messages in the conversation that would otherwise be hard-deleted by the reaper, and their attachments, are left alone until the hold is released.
• Redaction is refused. Calling the redact action on a held conversation returns a validation error telling you to clear the hold first.

Releasing the hold puts normal retention and redaction back in force; it does not retroactively delete anything that was preserved while the hold was on — the next reaper pass simply becomes eligible to act on it again.

legal_hold is an enum rather than a boolean, so new states can be added without a breaking change. Today it is only ever released (the default) or held.

Redaction

Redaction is the right-to-erasure action. It is irreversible.

curl -X POST API_HOST/v1/messaging/conversations/cv_w35z4ck68yq7/actions/redact \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Augno-Version: CURRENT_API_VERSION" \
  -H "Augno-Account: YOUR_ACCOUNT_ID"

It requires the messaging:delete permission and takes no body. In one pass it:

1. deletes every live attachment on the conversation from object storage, then deletes the attachment rows — objects first, so a failure part-way through retries the object deletion rather than orphaning it;
2. clears the body and the preview text of every message in the conversation that has not already been deleted, and stamps each one as edited;
3. writes an audit event recording the redaction and pushes a conversation-updated event to connected clients.

What survives redaction

The messages are kept as an audit shell — the rows do not disappear, so the shape of the conversation stays verifiable. That means redaction removes content, not evidence that a conversation happened. Specifically, the following are not cleared:

• the conversation itself, including its title, participants, linked records, and case status;
• each message's id, sequence, timestamps, kind, visibility, and sender attribution;
• for email-bridged cases, the delivery metadata Augno recorded for each mail — including the external sender's address, the subject line, and the raw message stored in object storage when it arrived.

If an erasure request covers that metadata too, handle it as a manual data-subject request; the redact action alone does not reach it.

Order of operations

Because a hold blocks redaction, the sequence for a conversation that is under hold and subject to an erasure request is: release the hold, redact, and re-apply the hold if the matter is still live. Redacting first is not possible, and the API will not silently ignore the hold.

What the retention worker deletes

A background worker prunes expired messaging rows on a fixed schedule. It runs hourly, only one instance runs at a time across the fleet, and each pass deletes in bounded batches (up to 1,000 rows per statement), so a large backlog drains over several passes rather than in one sweep.

A few details behind the table:

• The 180-day rule is a hard cap. It exists so an unattended notification feed cannot grow without bound, and it applies whether or not the recipient ever opened the notification.
• When announcements are purged, receipts left pointing at an announcement that no longer exists are cleaned up in the same pass.
• Attachments of a tombstoned message are always removed before the message row itself: the storage object is deleted first, then the attachment row, and the message is only hard-deleted once its attachments are gone. A conversation under legal hold is skipped at both steps.

These windows are platform defaults and are not configurable per account.

What is not on a timer

• Live messages and conversations are retained indefinitely. There is no automatic expiry of an active conversation, and no account-level "delete messaging data after N days" setting. Removing content is an explicit action — redaction — not a retention policy.
• The 30-day message window has nothing to act on today. Sent messages cannot be deleted through the API, and no product action currently tombstones one either, so the reaper's message pass finds no eligible rows. Treat that row of the table as the rule the worker would apply, not as a clock running on your content. Removing message content is redaction, and redaction leaves the rows in place.
• The worker covers messaging rows only. Email logs, audit events, and request logs are outside its scope and are not affected by the windows above.

Related reading