Data Retention

Retention uses one canonical commercial grid plus one distinct technical setting. You need to distinguish between:

• the canonical workspace plan retention target
• the derived self-serve API read window enforced on /v1/*
• the site-level technical retention setting in Settings > Sites > Collection

Public workspace retention

Plan	Public retention target
Free	60 days
Starter	13 months
Pro	24 months
Enterprise	Custom

Self-serve API retention

Plan	API read retention (derived)
Free	Not included
Starter	395 days
Pro	730 days

Free does not include self-serve API access. Starter and Pro expose the derived day-form above on the active /v1/* read surface.

At launch, those API read windows are derived from the same canonical plan-retention grid shown above. They are not a second commercial retention table. They remain distinct only from the site-level technical retention setting and from the internal raw-data storage ceiling described in the public privacy policy.

The runtime API keeps the retention split explicit:

• GET /v1/me exposes product/API retention in product.product_retention.api_retention_days
• GET /v1/sites exposes the separate site-level technical retention in product_configuration.technical_retention.site_data_retention_months

What happens when API retention is exceeded

If a request asks for data older than your plan retention, the API returns:

• HTTP 422
• Error code RETENTION_EXCEEDED
• error.details.min_allowed_from indicates the earliest allowed date

{
  "error": {
    "code": "RETENTION_EXCEEDED",
    "message": "Query start is outside plan retention",
    "request_id": "req_...",
    "details": {
      "min_allowed_from": "2025-12-31"
    }
  }
}

Adjust your from parameter to be within the retention window.

Legacy date parameters

Public /v1/* routes require from and to.

The older start / end parameters are no longer part of the public runtime surface. They still exist only on the internal dashboard /metrics/* shared contract.