Data retention and zero data retention

This page says what Syntic keeps when you use the API, for how long, and what changes when your organization runs in zero data retention (ZDR) mode. Every API feature has a row in the table below; a feature is not released until its row is filled in.

What the chat completions API keeps today

For each POST /v1/chat/completions request, Syntic records a usage record: the organization, the member or key, the model, token counts (prompt, completion and cached), the cost, whether the plan or credits paid, the status and the request ID. The usage record does not contain your prompts, your files or the model’s reply.

Prompts and replies pass through Syntic to the model and back. Syntic does not write them to its own database. For ZDR organizations, the model service is also told not to store the request.

Retention by feature

Zero data retention mode

ZDR is an organization-wide setting for customers who must not have prompt and output content stored at rest outside their own systems, for example under healthcare or financial regulation. Today it is switched on with the HIPAA add-on. A plain ZDR switch without the add-on is planned for Enterprise organizations.

With ZDR on:

• Only models whose serving path guarantees no storage can be used. Others return 400 model_unavailable before anything is billed. GET /v1/models marks eligible models with zero_data_retention: true.
• Features that cannot work without storing content are refused with 403 permission, code feature_unavailable_zdr, or limited as the table says.
• Usage records, billing and audit events continue; they contain no content.
• The setting is recorded in the audit log whenever it changes.

If the platform cannot confirm whether an organization is in ZDR mode, it treats the organization as ZDR (fail closed).

Organization retention period

Owners will be able to set a shorter retention period for stored content in organization settings: 7, 30, 90 or 365 days. The same setting already controls how long conversations are kept in Syntic’s own chat product. It applies to every content-holding feature in the table whose default is longer. A shorter setting on an individual resource (for example a file’s expires_after_days) always wins.

With the Admin API the same setting is readable at GET /v1/organizations/me under settings.data_retention_days and writable by Owners with PATCH /v1/organizations/me.

curl -sS https://app.syntic.ai/v1/organizations/me \
  -H "Authorization: Bearer $SYNTIC_ADMIN_KEY" \
  -H "syntic-beta: admin-2026-11-01" \
  | jq '.settings | {zero_data_retention, data_retention_days}'

const res = await fetch('https://app.syntic.ai/v1/organizations/me', {
  headers: { Authorization: `Bearer ${process.env.SYNTIC_ADMIN_KEY}`, 'syntic-beta': 'admin-2026-11-01' },
})
const { settings } = await res.json()
console.log(settings.zero_data_retention, settings.data_retention_days)

import os, requests
 
org = requests.get(
    "https://app.syntic.ai/v1/organizations/me",
    headers={"Authorization": f"Bearer {os.environ['SYNTIC_ADMIN_KEY']}", "syntic-beta": "admin-2026-11-01"},
).json()
print(org["settings"]["zero_data_retention"], org["settings"]["data_retention_days"])

Deleting data

• Resources you create (files, sessions, memory stores, vaults, batches) can each be deleted through their own DELETE endpoint at any time. Deletion removes them from use immediately and from backups within 30 days.
• To delete everything about one end user, delete the sessions you tagged with their contact.id and the memory scope you used for them.
• Closing an organization deletes all stored content within 30 days. Usage and billing records are kept as required by tax law.

Errors

Build notes for the platform team

• Every new feature’s design doc declares its row in the table above, including ZDR behaviour, before build starts.
• Enforce retention with the existing scheduled cleanup function, extended per feature table; record each purge in a retention-jobs log.
• Fail closed on ZDR lookups, as chat completions does today.

Related

• Data residency
• Customer-managed keys
• Models overview
• Audit logs