Skip to main content

Execute Resolution

Start a pending resolution run with POST /v1/resolutions/{id}/execute: returns immediately with processing status; poll the run to detect completion or failure.

Execute a resolution run to start applying the frozen normalization configuration to the source run's extracted values. The call flips the run to processing and returns immediately — all pipeline work happens asynchronously in the background. Poll [GET /v1/resolutions/{id}](get-resolution) to track the status, and read the [results](get-resolution-results) once it reaches completed.

Execution is guarded by the run's lifecycle state: a pending run starts normally, and a failed run can be re-executed in place — the same run row transitions back to processing and tries again, which is the intended retry path after a transient failure. A run that is already processing is rejected with 400 ("Resolution run is already processing"), as is a run that already completed ("Resolution run is already completed"); to resolve the same job again after completion, create a new resolution run.

Under the hood the executor works in batches, flushing each batch of resolved documents to the result rows before starting the next. This is why partial results are readable mid-run, and why a retried run does not start from zero: documents whose result row already completed are skipped on re-execution, so retrying after an infrastructure failure only redoes the unfinished remainder.

Deterministic rules (reference lookups, computes, format constraints) complete in seconds even for large runs. Policies that invoke LLM-assisted matching for values no deterministic rule could settle take longer — typically 1-5 minutes depending on how many values need model calls. Budget polling intervals accordingly rather than tight-looping.

Execute is not idempotent from the caller's perspective: a 400 on an already-processing or already-completed run is an expected state signal, not an error to retry. Treat 400 responses here as "check the run status", not "back off and resend".
POST/v1/resolutions/{id}/execute

Path parameters

id*uuidResolution run UUID.

curl

curl -s -X POST https://api.talonic.com/v1/resolutions/a1b2c3d4-e5f6-7890-abcd-ef1234567890/execute \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

Response fields

idstringResolution run UUID.
source_run_idstringUUID of the originating job run.
statusstringprocessing after a successful trigger.
policy_snapshotobject | nullThe frozen normalization config the execution applies.
dialect_snapshotobject | nullThe frozen dialect configuration, or null.
error_messagestring | nullCleared on a fresh trigger; populated only after a failure.
created_atstringISO 8601 creation timestamp.
updated_atstringISO 8601 timestamp of this transition.
linksobjectRelated resource URLs: self, results, source_run.

Response

{
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "source_run_id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
  "status": "processing",
  "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:33:05.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

400bad_requestThe run is already processing, or already completed. Check the run status instead of retrying.
401unauthorizedMissing or invalid API key.
404not_foundResolution run not found or does not belong to your organization.
429rate_limitedDaily request quota for your tier reached. The counter resets at midnight UTC.

Frequently asked questions

Is the execute call synchronous?+
No. The call transitions the run to processing and returns immediately; all pipeline work runs in the background. Poll GET /v1/resolutions/{id} to track progress and detect the terminal completed or failed status.
What happens if execution fails?+
The run transitions to failed with the detail in error_message. Call execute again on the same run to retry in place — documents whose result rows already completed are skipped, so the retry only redoes the unfinished remainder.
Can I execute the same resolution twice?+
Not while it is processing or after it completed — both return 400 with a message naming the state. A failed run is the exception: re-executing it is the supported retry path. To resolve the same job again after completion, create a new resolution run.
Does executing again re-resolve everything?+
No. Execution flushes results in batches, and a re-trigger after failure skips documents whose result row is already completed. This makes retries cheap: an infrastructure hiccup near the end of a large run costs one batch, not the whole run.