Skip to main content

Node Jobs

Run a single engine stage at a time with the node jobs API: transfer, extract, resolve, validate, or assemble over a shared record set chained by record_set_id.

Node jobs expose the individual stages of Talonic's structuring pipeline as standalone API primitives. Where a Spec pipeline runs the whole rail end to end, node jobs let you run one stage at a time (Transfer, Extraction, Resolution, Validation, or Assembly) and chain them yourself over a shared record set. Each call is asynchronous: it returns 202 with a node-run id you poll for status and results.

The typical chain starts with POST /v1/nodes/transfer (or extract) against a set of document_ids and a schema_id, which creates a record set and fills cells. Each subsequent stage takes the record_set_id from the previous one: extract fills gaps the registry could not, resolve applies Data Policies, validate runs your gates, and assemble composes grouped documents into a product record set. This gives you fine-grained control over the structuring flow when a single Spec run is too coarse.

Node jobs are the primitive tier: they write cells and verdicts but never create review-queue holds or block fields. Most integrations should run a configured Spec via POST /v1/pipelines, which compiles the whole rail in one call and enforces the governed review flow.

Stage endpoints

POST/v1/nodes/transfer

Body parameters

schema_id*stringThe schema whose cells are filled from the Field Registry.
document_ids*string[]Documents to process. Must already be ingested and registry-extracted.
POST/v1/nodes/extract

Body parameters

schema_id*stringThe schema to extract against.
document_idsstring[]Start a fresh canvas over these documents. Mutually exclusive with record_set_id.
record_set_idstringExtract into an existing record set (e.g. after a transfer node). Already filled fields are skipped.
field_keysstring[]Optional. Scope extraction to a subset of the schema's fields.
POST/v1/nodes/resolve

Body parameters

record_set_id*stringThe record set whose cells the policies resolve.
policy_ids*string[]Data Policy UUIDs to apply, executed in array order.
POST/v1/nodes/validate

Body parameters

record_set_id*stringThe record set to validate.
schema_id*stringThe schema the record set was structured against.
validation_stage_idstringOptional. A saved validation stage to run.
gateobjectOptional inline gate config: { evidence?, nshot?, llmJudge?, businessRules?, groundTruth? }. Default is structural evidence checks only (n-shot off, to bound cost).
POST/v1/nodes/assemble

Body parameters

record_set_id*stringThe record set to compose from.
assembly_config*objectAssembly configuration. Requires grouping_field and anchor_field.
assembly_config.grouping_field*stringField whose value groups documents into one composed record.
assembly_config.anchor_field*stringField used to pick the Anchor document within each group.
assembly_config.anchor_valuesstring[]Values of anchor_field that mark a document as the Anchor.
assembly_config.signed_fieldstringOptional field indicating signed documents.
assembly_config.date_fieldstringOptional field used to order documents in a group.
assembly_config.amendable_fieldsstring[]Fields that Amendment documents may override on the composed record.

Request: start a transfer node

curl -X POST https://api.talonic.com/v1/nodes/transfer \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "schema_id": "sch_uuid_1",
    "document_ids": ["doc_uuid_1", "doc_uuid_2"]
  }'

The node run object

Every stage endpoint returns 202 Accepted with a node run: a standalone run of a single engine stage over a record set. Cell-producing stages carry the record_set_id you chain into the next stage; an assembly run additionally carries product_record_set_id for the composed records.

Node run fields

idstringNode run UUID. Poll it via GET /v1/nodes/:id.
node_typestringStage type: transfer, extraction, resolution, validation, assembly.
statusstringRun status: queued, running, completed, partial, error.
record_set_idstring | nullThe record set the run reads and writes. Chain this into the next stage.
product_record_set_idstring | nullComposed product record set. Set by assembly runs.
totalintegerTotal work items in the run.
completedintegerWork items completed so far.
errorsintegerWork items that errored.
error_messagestring | nullError detail when the run fails.
created_atstringISO 8601 creation timestamp.
linksobjectRelated resource URLs.

Response (202 Accepted)

{
  "id": "nr_uuid_1",
  "node_type": "transfer",
  "status": "queued",
  "record_set_id": "rs_uuid_1",
  "product_record_set_id": null,
  "total": 2,
  "completed": 0,
  "errors": 0,
  "error_message": null,
  "created_at": "2024-09-14T10:32:00.000Z",
  "links": {
    "self": "/v1/nodes/nr_uuid_1",
    "results": "/v1/nodes/nr_uuid_1/results"
  }
}

Polling a node run

Each stage call returns a node-run id. Poll GET /v1/nodes/:id for its status and progress counters, and read GET /v1/nodes/:id/results once it completes. For a validation node, results are the per-record and per-field verdicts. For cell-producing nodes (transfer, extract, resolve, assemble), results point you to the record-set read endpoints where the cells live. Carry the record_set_id forward to the next stage to chain the pipeline.

GET/v1/nodes/:id
GET/v1/nodes/:id/results

Errors

Error responses

400bad_requestInvalid request body, e.g. extract given both document_ids and record_set_id, or assembly_config missing grouping_field or anchor_field.
401unauthorizedMissing or invalid API key.
403forbiddenThe API key lacks the scope required by the endpoint (write for stage runs, read for polling).
404not_foundSchema, document, record set, policy, or validation stage not found for your organization.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Frequently asked questions

When should I use node jobs instead of a pipeline?+
Use a pipeline (`POST /v1/pipelines`) for the normal end-to-end run of a configured Spec. Use node jobs when you need to drive individual stages, for example to inspect the record set between transfer and extraction, or to branch resolution across different Data Policies.
How do stages share state?+
Through the `record_set_id`. The first stage (transfer or extract) creates a record set; pass that id to each subsequent stage so they operate on the same cells. Assembly additionally produces a separate `product_record_set_id` holding the composed records.
Do node jobs enforce review holdback?+
No. Node jobs are the primitive tier: a validation node writes flagged cell status and verdicts, but it never creates review-queue holds or blocks fields. That governed flow is exclusive to Spec runs via `POST /v1/pipelines`.
Can I extract only some fields of a schema?+
Yes. Pass `field_keys` to `POST /v1/nodes/extract` to scope the LLM extraction to a subset of the schema's fields. When extracting into an existing record set, already filled fields are skipped automatically.
Where do I read the extracted cells?+
From the record-set endpoints. `GET /v1/nodes/:id/results` on a cell-producing node returns a pointer to the record set; read its rows through the record-set read endpoints using the run's `record_set_id` (or `product_record_set_id` after assembly).