With zero data retention, your message content and data are never written to our database. Text, attachments, poll options, mentions, and edits pass through Linq in memory, get delivered, and are gone.
In this post, we'll cover what a zero data retention line does, what changes for your integration, and how to turn it on.
What zero data retention means
On a zero data retention line, content is shown to you exactly once on each side. When you send a message, the synchronous response to your POST echoes the content back. When you receive one, the first webhook for that message (message.received) carries the content. After that, every read is empty. Later status webhooks such as message.sent, message.delivered, and message.read arrive with "parts": [], and any GET, list, or thread call for that message returns empty content fields.
It looks like this:
{
"event_type": "message.delivered",
"data": {
"id": "b2c3d4e5-0000-0000-0000-000000000001",
"parts": [],
"zero_retention": true
}
}
Every affected webhook carries a zero_retention boolean. There is no endpoint that reports a line's retention setting. Everything is handled per event.
Attachments follow the same rule with one mechanical difference. The attachment URL you receive works for exactly one download. The first GET returns the file bytes with a 200, and the file is deleted after that successful fetch. A second request to the same URL returns a 404 with error code 2003.
What changes for your integration
Log the message on your side the first time it appears. That is the only time we have it to hand to you.
Two flows change, with zero data retention:
First, adding options to an existing poll normally sends only the new option, because the existing options are on file. On a zero data retention line they are not, so you resend every existing option in creation order followed by the new ones; omitting one returns a 400 with error code 1005.
Second, updating an app card in place with url or raw_payload_data normally inherits the original card's app identity. On a zero data retention line you supply the app object (name, team_id, bundle_id) yourself. Cards built from an experience are unaffected.
How this differs from ephemeral messaging
In July we shipped ephemeral messaging, which stores content encrypted and scrubs it on a hard 24-hour timer. Ephemeral messaging is the right choice when you want reactions, replies, and edits to keep resolving against stored content for a short window. Zero data retention removes the window. Content is never written, and you take responsibility for capturing anything you need on first sight.
Get started
Zero data retention is available today on all plans and is enabled per phone number, so you can run it on the lines that handle sensitive conversations and leave the rest unchanged. Contact us to enable it on a line, then read the zero data retention guide for the full table of what is shown once, what persists, and every error code involved.
