Skip to main content

List Data Policies

List data policies: versioned rulesets that transform, normalize, and validate extracted field values during resolution runs. Cursor-paginated, read scope.

A data policy is a first-class, versioned ruleset that defines how extracted field values are transformed, normalized, and validated during resolution. Resolution is the application of Data Policies to extracted values — distinct from the registry's internal binding of raw field names to canonical fields. Each policy declares a set of output fields (the contract) and a set of rules (the transformation logic), which the platform compiles into an executable pipeline. This endpoint lists every data policy in your workspace with cursor-based pagination.

Policies power the Resolve stage of a pipeline: lookup cascades that map raw values to canonical codes via reference tables, sandboxed Lua scripting for custom logic, deterministic computation, and field-to-field transforms. Because policies are versioned, you can iterate on transformation logic without affecting in-flight resolution runs that already captured a policy snapshot.

Two execution paths consume a policy. A Spec pipeline's Resolve stage compiles the referenced policy automatically at run time and writes the transformed values back into the run's structured output, so pipeline results already reflect the policy's work. A standalone [resolution run](execute-resolution) applies a policy on demand and produces a resolved output you can compare against its input. Both paths execute the same rule engine, so a policy authored once behaves identically in either.

Results are ordered by creation date, newest first by default. Pagination is keyset-based: the opaque cursor encodes the last row's creation timestamp and id, so pages stay stable while new policies are being created, and pagination.total is counted before the cursor applies, so it stays constant across pages. Pass the next_cursor from a previous response as cursor to fetch the next page, and order=asc to walk the list oldest first. This endpoint requires an API key with the read scope.

GET/v1/data-policies

Query parameters

limitintegerMaximum number of items to return (1-100). Default: 20
cursorstringOpaque pagination cursor from a previous response.
orderstringSort order by creation date (asc | desc). Default: desc

Response

Response fields

dataarrayArray of data policy objects.
data[].idstringData policy UUID.
data[].namestringHuman-readable policy name.
data[].descriptionstring | nullOptional description of the policy purpose.
data[].statusstringPolicy status (e.g. draft, published).
data[].created_atstringISO 8601 creation timestamp.
data[].updated_atstringISO 8601 last update timestamp.
data[].linksobjectURLs to the policy and its subresources (self, versions, fields, rules).
pagination.totalintegerTotal number of policies in the workspace.
pagination.limitintegerMaximum results per page.
pagination.has_morebooleanWhether more results exist beyond this page.
pagination.next_cursorstring | nullCursor to fetch the next page. Null if no more results.

curl

curl -s https://api.talonic.com/v1/data-policies \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

{
  "data": [
    {
      "id": "p1a2b3c4-e5f6-7890-abcd-ef1234567890",
      "name": "Invoice Normalization",
      "description": "Standardize currency codes, country names, and date formats for invoice processing",
      "status": "published",
      "created_at": "2024-10-01T09:00:00.000Z",
      "updated_at": "2024-10-15T11:30:00.000Z",
      "links": {
        "self": "/v1/data-policies/p1a2b3c4-e5f6-7890-abcd-ef1234567890",
        "versions": "/v1/data-policies/p1a2b3c4-e5f6-7890-abcd-ef1234567890/versions",
        "fields": "/v1/data-policies/p1a2b3c4-e5f6-7890-abcd-ef1234567890/fields",
        "rules": "/v1/data-policies/p1a2b3c4-e5f6-7890-abcd-ef1234567890/rules"
      }
    }
  ],
  "pagination": {
    "total": 1,
    "limit": 20,
    "has_more": false,
    "next_cursor": null
  }
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.
Policies are versioned. The list shows the policy headers; follow links.versions to see the compiled version history and links.fields / links.rules for the current contract and logic.

Frequently asked questions

What do data policies do?+
Data policies define how extracted field values are transformed and normalized during resolution runs. They support lookup cascades (mapping raw values to canonical codes via reference tables), sandboxed Lua scripting for custom logic, deterministic computation, and field-to-field transforms.
How do data policy versions work?+
A policy's fields and rules live on versions, and a resolution run captures a snapshot of the policy at run time, so later changes never retroactively affect completed runs. You can inspect which configuration a run used via the `policy_snapshot` on the resolution run.
Can I have multiple data policies per workspace?+
Yes. You can create as many policies as you need for different transformation scenarios, for example one per document family. A pipeline's Resolve stage references the specific policies it should apply.
How does a pipeline pick which policy to apply?+
The Spec's Resolve stage references policies by UUID — they appear as `policy_ids` on the rail stage returned by `GET /v1/specs/{id}`. When the pipeline runs, the Resolve phase compiles the referenced policy and applies it to every record. The same policy can be referenced from multiple Specs.