Skip to main content

Get Data Policy

Retrieve a data policy by ID with its current version's fields and rules inlined: the full output contract, transform logic, and execution order in one call.

Retrieve one data policy with its fields and rules inlined, giving you the entire transformation configuration in a single call. The inlined fields and rules are read from the policy's current version, so what you see is exactly what a resolution run would execute. This is the endpoint for auditing transformation logic or debugging resolution results.

The fields array is the output contract: which field keys the policy emits and their data types. The rules array is the logic: each rule declares its rule_type, the input field keys it reads, the output field key it writes, its configuration, and its position in the compiled execution order. Rules execute in dependency order, so upstream values exist before downstream rules read them.

Use this read to debug a resolution: when a resolved value looks wrong, find the rule whose output_field_key matches the field, check its execution_order to see what ran before it, and inspect config for the lookup table or script it applied. error_behavior tells you what the executor did on failure — a rule set to flag keeps the value but marks it for review, which is why a failed lookup can still show a value in the output.

The response also carries the policy header — status, timestamps, and the links object with the subresource URLs — so one call gives you everything needed to render, audit, or export the policy. Exporting this JSON into version control before editing gives you a recoverable record of the configuration: the API has no rollback, so re-applying an exported contract is the way back to a known-good state.

GET/v1/data-policies/{id}

Path parameters

id*uuidData policy UUID.

Response

Response fields

idstringData policy UUID.
namestringPolicy name.
descriptionstring | nullPolicy description.
statusstringPolicy status (e.g. draft, published).
fieldsarrayDeclared output fields from the policy's current version.
fields[].idstringField row UUID.
fields[].field_keystringOutput field key name.
fields[].data_typestringDeclared value type (e.g. string, number, date).
fields[].source_schema_field_idstring | nullSchema field this output is bound to, if any.
fields[].positionintegerDisplay/output order of the field.
rulesarrayTransformation rules from the policy's current version, in execution order.
rules[].idstringRule UUID.
rules[].rule_typestringRule type (e.g. select_field, transform, lookup_exact, script).
rules[].input_field_keysarrayField keys the rule reads.
rules[].output_field_keystring | nullField key the rule writes.
rules[].configobjectRule-type-specific configuration.
rules[].execution_orderintegerPosition in the compiled execution order.
rules[].error_behaviorstring | nullWhat happens when the rule fails (e.g. flag, set_empty, skip, fail, default_value, ignore).
linksobjectURLs to the policy and its subresources (self, versions, fields, rules).
created_atstringISO 8601 creation timestamp.
updated_atstringISO 8601 last update timestamp.

curl

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

Response

{
  "id": "p1a2b3c4-e5f6-7890-abcd-ef1234567890",
  "name": "Invoice Normalization",
  "description": "Standardize currency codes, country names, and date formats",
  "status": "published",
  "fields": [
    {
      "id": "f1a2b3c4-0001",
      "field_key": "country_code",
      "data_type": "string",
      "source_schema_field_id": null,
      "position": 1
    }
  ],
  "rules": [
    {
      "id": "r1a2b3c4-0001",
      "rule_type": "lookup_exact",
      "input_field_keys": ["country"],
      "output_field_key": "country_code",
      "config": { "reference_table_id": "country_codes", "search_column": "name", "output_column": "iso2" },
      "execution_order": 1,
      "error_behavior": "flag"
    }
  ],
  "created_at": "2024-10-01T09:00:00.000Z",
  "updated_at": "2024-10-15T11:30:00.000Z"
}

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 freshly created policy returns empty fields and rules arrays — version 1 exists from creation, but nothing is authored on it yet. The inlined configuration always reflects the current version, not historical ones.

Frequently asked questions

Why are fields and rules inlined in the response?+
Inlining fields and rules gives you a complete view of the policy in a single API call. This is useful for auditing the full transformation pipeline, debugging resolution results, or exporting the policy configuration for version control.
What are the supported rule types?+
Policies support 14 rule types: `select_field`, `transform`, `auto_transform`, `lookup_exact`, `lookup_fuzzy`, `compute`, `script` (Lua), `coalesce`, `conditional`, `temp_var`, `chain`, `validate`, `highlight`, and `bypass`. Each has its own configuration schema.
How does rule execution order work?+
Rules are compiled into a topological order based on their input and output field keys. A rule that reads `country` and writes `country_code` always executes after the rule that produces `country`. Circular dependencies are detected at compile time.
What does error_behavior control?+
It decides what happens when a rule fails for a record: `flag` keeps the value but marks it for review, `set_empty` clears it, `default_value` substitutes a configured fallback, `skip` and `ignore` leave the record untouched, and `fail` stops with an error.