Skip to main content

Rerun Pipeline

Rerun a finished document processing pipeline from a chosen phase onward. Earlier phases reuse their stored cells; prior human review decisions are preserved.

POST /v1/pipelines/{id}/rerun re-runs a finished pipeline from a chosen phase onward. The named phase and everything after it re-execute; every phase before it reuses its stored cells untouched. This is how you re-resolve or re-validate a run after tuning a policy or a gate, without paying to re-extract documents that already extracted cleanly.

Every document must be terminal before a rerun. A run with documents still processing is rejected with 400. The rerun resets field states so the phase loop sees active fields again, but prior human decisions in the review decision log survive: a gate a reviewer already approved or overrode does not re-block. A blocking validation gate positioned before the rerun start keeps its blocked fields, since that gate is not re-executed.

The from_phase value must be one of transfer, extraction, resolution, matching, or validation, and the run must actually contain a phase of that type. Re-running from resolution re-resolves and re-validates while keeping extraction; re-running from validation re-validates only. When the first phase of the requested type is pipeline-scoped (a post-assembly gate), the rerun routes to the assembly rerun instead, re-composing and re-running the whole post-assembly tail so its verdicts are regenerated rather than wiped. After a rerun finishes, recreate the data product to rebuild its review queue. This endpoint requires an API key with the write scope.

A rerun is also gated by governance state: if an active blocking Business Rule hold covers any of the run's submission groups, the request is rejected with 409 naming the held group count — review or override the hold first. This mirrors the delivery gate, so a run that cannot deliver cannot silently re-process either.

A rerun requires every document in the run to be terminal (complete, partial, or error). Attempting to re-run while any document is still processing returns 400 bad_request.
POST/v1/pipelines/{id}/rerun

Body parameters

from_phase*stringPhase type to re-run from (and everything after it): one of transfer, extraction, resolution, matching, validation.

Request

curl -X POST https://api.talonic.com/v1/pipelines/a1b2c3d4-e5f6-7890-abcd-ef1234567890/rerun \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "from_phase": "resolution" }'

Response

Response fields

enqueuedintegerNumber of documents re-enqueued for processing.
fromPhaseIndexintegerZero-based index of from_phase in the run's compiled phase config.

Response

{
  "enqueued": 24,
  "fromPhaseIndex": 2
}

fromPhaseIndex is the zero-based index of the first re-executed phase in the run's compiled phase config (compare it against the plan from GET /v1/pipelines/{id}?include=phases), and enqueued is how many documents were re-queued. After the rerun starts, the run behaves like a fresh in-flight pipeline: poll progress the same way, and expect the re-executed phases' counters to reset to pending while earlier phases stay completed.

Re-validate only, then poll

curl -s -X POST https://api.talonic.com/v1/pipelines/a1b2c3d4-e5f6-7890-abcd-ef1234567890/rerun \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "from_phase": "validation" }'
# => { "enqueued": 24, "fromPhaseIndex": 3 }

curl -s https://api.talonic.com/v1/pipelines/a1b2c3d4-e5f6-7890-abcd-ef1234567890/progress \
  -H "Authorization: Bearer $TALONIC_API_KEY" | jq '{status, completedDocuments, totalDocuments}'

Errors

Error responses

400bad_requestDocuments are still processing, the run has no phase of the requested type, the run has no record set, or the body failed validation.
401unauthorizedMissing or invalid API key.
404not_foundNo pipeline with this ID exists for your organization.
409RESOURCE_CONFLICTAn active blocking Business Rule hold covers one or more of the run's submission groups. Review or override the hold, then retry.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Frequently asked questions

Will a rerun re-block fields a reviewer already approved?+
No. Prior human decisions survive the rerun, so a gate a reviewer approved or overrode does not re-block. A field that was corrected and still fails is a new review item, since a correction is not a guarantee the new value passes.
Does re-running from validation re-extract documents?+
No. Re-running from `validation` keeps every prior phase's stored cells and only re-runs validation. Re-running from `resolution` keeps extraction but re-resolves and re-validates.
Can I re-run a post-assembly gate?+
Yes — name its phase type as from_phase. When the first phase of that type is pipeline-scoped, the request routes to the assembly rerun: the composed record is rebuilt and the entire post-assembly tail (resolution and every gate) re-executes, so verdicts are regenerated rather than cleared and skipped.
What do I do after the rerun finishes?+
Recreate the data product with `POST /v1/pipelines/{id}/data-product`. That rebuilds the review queue from the rerun's stored validation verdicts, so the delivery surface reflects the new results.

Related

Pipeline Progress
Get Pipeline
Pipeline Results
Create Data Product from Pipeline