Skip to main content

List Data Policy Versions

List the version history of a data policy: each version snapshots the ruleset with its status and compiled execution plan, for audit and run correlation.

Retrieve the version history of a data policy. Each version is a snapshot of the policy's configuration at a point in time, carrying its own status and, once compiled, the compiled execution plan. Versions are created as the policy's fields and rules are authored and revised, so the history shows how the transformation logic evolved.

Version numbers are monotonically increasing integers starting at 1, returned newest first. When a resolution run captures a policy snapshot it records the version it executed, so you can correlate resolution results with the exact configuration that produced them.

A policy has a version from birth: creating a policy over the API mints version 1 as a draft in the same transaction, so this list is never empty for a policy you created. Authoring forks the current version when needed and appends new rows as the logic is revised; the policy's current-version pointer decides which configuration GET /v1/data-policies/{id} inlines and which one a new resolution executes.

Use the history for audit and correlation rather than rollback: the API cannot re-activate an old version directly. To pin behavior, record the version number your integration was validated against and alert when a newer version appears; to restore old behavior, re-author the old configuration, which appends a fresh version rather than mutating history.

GET/v1/data-policies/{id}/versions

Path parameters

id*uuidData policy UUID.

Response

Response fields

dataarrayArray of version objects, newest first.
data[].idstringVersion UUID.
data[].version_numberintegerVersion number (monotonically increasing).
data[].statusstringVersion status (e.g. draft, active).
data[].compiled_rulesobject | nullCompiled execution plan for this version, when compiled.
data[].compile_statusstring | nullLatest compile outcome for the version, or null if never compiled.
data[].compiled_atstring | nullISO 8601 timestamp of the last successful compile.
data[].dirtybooleanTrue when the version has been edited since it was last compiled.
data[].created_atstringISO 8601 timestamp when this version was created.
links.selfstringURL to this version list.
links.policystringURL to the parent policy.

curl

curl -s https://api.talonic.com/v1/data-policies/p1a2b3c4-e5f6-7890-abcd-ef1234567890/versions \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

{
  "data": [
    {
      "id": "v3a2b3c4-0003",
      "version_number": 3,
      "status": "active",
      "compiled_rules": { "steps": 8 },
      "compile_status": "ok",
      "compiled_at": "2024-10-15T11:31:00.000Z",
      "dirty": false,
      "created_at": "2024-10-15T11:30:00.000Z"
    },
    {
      "id": "v2a2b3c4-0002",
      "version_number": 2,
      "status": "draft",
      "compiled_rules": null,
      "compile_status": null,
      "compiled_at": null,
      "dirty": true,
      "created_at": "2024-10-10T14:00:00.000Z"
    }
  ],
  "links": {
    "self": "/v1/data-policies/p1a2b3c4-e5f6-7890-abcd-ef1234567890/versions",
    "policy": "/v1/data-policies/p1a2b3c4-e5f6-7890-abcd-ef1234567890"
  }
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
404not_foundData policy not found or does not belong to your organization.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.
A version compiles on use: when a pipeline's Resolve stage runs an uncompiled version, the platform compiles it first and persists the plan, so compiled_rules fills in the first time the version actually executes.

Frequently asked questions

How do I see which version a resolution used?+
The `policy_snapshot` captured on a resolution run records the configuration it executed. Compare it with this version list to identify which version was active when the resolution ran.
Can I roll back to a previous version?+
The API does not support direct rollback. To revert to a previous configuration, inspect the version history and re-apply the desired fields and rules, which produces a new version with the old configuration.
What is in compiled_rules?+
The compiled execution plan for the version: the rule set resolved into a validated, topologically ordered pipeline. It is populated when the version is compiled, which happens automatically the first time the version is executed.
Why does a brand-new policy already have a version?+
POST /v1/data-policies creates version 1 (status `draft`) atomically with the policy itself, and every downstream edit resolves the editable version from that row — a policy without a version would be uneditable. The version list therefore always starts at 1.
How do I read the current configuration without the history?+
Use GET /v1/data-policies/{id}: it inlines the current version's fields and rules — the exact configuration the next resolution executes. Reach for the version list only when you need the historical trail or want to correlate a past resolution with the version that produced it.

Related

Get Data Policy
Update Data Policy
Resolutions