Skip to main content

List Resolutions

List resolution runs that apply Data Policies to extracted values with GET /v1/resolutions: filter by status or source_run_id, newest first, up to 100 runs.

Resolution means applying Data Policies — versioned normalization rulesets — to the field values produced by a completed job run. A resolution run standardizes raw extracted values so that values like country names, units, or vendor identifiers are mapped to canonical forms against your reference data. The source run's extracted grid is read-only input: resolution never re-runs OCR or extraction, and its output lives in its own result rows.

A resolution run maps raw extracted values (e.g. "Deutschland") to canonical forms (e.g. "DE") through the normalization configured on the schema: reference-data lookups, deterministic computations, value transforms and modifiers, format constraints, and dialect shaping. At creation, the run freezes that configuration into a policy_snapshot (and, when the schema has a dialect wired, a dialect_snapshot), so each run is reproducible and independent — you can resolve the same job again later under a changed configuration without disturbing earlier results.

Resolution here always means applying Data Policies to values. It is unrelated to the internal registry process (sometimes also called "resolution" or binding) that maps raw extracted field names to canonical field registry entries — that happens automatically during extraction and is not part of this API.

This endpoint lists the resolution runs in your workspace, newest first, returning up to 100 runs in one response with no pagination cursor. Two optional filters narrow the list server-side: status restricts to runs in one lifecycle state (pending, processing, completed, or failed), and source_run_id returns only the resolutions created from a specific job run — the natural query when you want to know whether a job has already been resolved.

Each run in the list carries the same shape as [GET /v1/resolutions/{id}](get-resolution): identifiers, status, the frozen policy_snapshot and dialect_snapshot, an error_message for failed runs, and a links object pointing at the run itself, its results, and the source job run. Because snapshots embed the full per-field configuration, list responses can be large — filter by source_run_id where you can rather than paginating the whole workspace client-side.

GET/v1/resolutions

Query parameters

statusstringFilter by run status: pending, processing, completed, or failed.
source_run_iduuidOnly resolutions created from this job run.

Response

Response fields

dataarrayArray of resolution run objects, newest first (up to 100).
data[].idstringResolution run UUID.
data[].source_run_idstringUUID of the originating job run.
data[].statusstringRun status: pending, processing, completed, or failed.
data[].policy_snapshotobject | nullFrozen normalization config at creation: name, sanity_check, and the per-field rules (reference tables, modifiers, constraints, format rules).
data[].dialect_snapshotobject | nullFrozen dialect configuration at creation, or null when the schema has no dialect wired.
data[].error_messagestring | nullFailure detail when status is failed.
data[].created_atstringISO 8601 creation timestamp.
data[].updated_atstringISO 8601 last-transition timestamp.
data[].linksobjectRelated resource URLs: self, results, source_run.

curl

curl -s "https://api.talonic.com/v1/resolutions?status=completed&source_run_id=b2c3d4e5-f6a7-8901-bcde-f12345678901" \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

{
  "data": [
    {
      "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "source_run_id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
      "status": "completed",
      "policy_snapshot": {
        "name": "Resolution 42Docs Jul 14",
        "sanity_check": false,
        "fields": [
          {
            "field_name": "country",
            "display_name": "Country",
            "data_type": "string",
            "reference_table": "iso-countries",
            "modifiers": null,
            "format": null,
            "suppress_output": false,
            "output_name": null
          }
        ]
      },
      "dialect_snapshot": null,
      "error_message": null,
      "created_at": "2026-07-14T10:32:00.000Z",
      "updated_at": "2026-07-14T10:35:42.000Z",
      "links": {
        "self": "/v1/resolutions/a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "results": "/v1/resolutions/a1b2c3d4-e5f6-7890-abcd-ef1234567890/results",
        "source_run": "/v1/jobs/b2c3d4e5-f6a7-8901-bcde-f12345678901"
      }
    }
  ]
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
429rate_limitedDaily request quota for your tier reached. The counter resets at midnight UTC.

Frequently asked questions

What is the difference between a job run and a resolution run?+
A job run extracts raw field values from documents. A resolution run applies your normalization rules to those raw values, mapping them to canonical forms through reference-data lookups, computations, transforms, and format constraints. The job's extracted grid is never modified — resolution output lives in its own result rows.
How do I find the resolutions created from a specific job run?+
Pass the job run's UUID as the source_run_id query parameter — the filter is applied server-side. Combine it with status=completed to check whether a finished resolution already exists before creating a new one.
What statuses can a resolution run have?+
Four: pending (created but not started), processing (pipeline executing), completed (results available), and failed (terminal error, with detail in error_message). Runs move to processing only when you call the execute endpoint — creation alone never starts work.
Is the list paginated?+
No. The endpoint returns up to 100 runs, newest first, with no cursor. Use the status and source_run_id filters to keep responses focused; the snapshots embedded in each run make unfiltered listings large in busy workspaces.