Runs & results

Start a run by submitting a document — through the UI, or by calling POST /v3/workflows/{workflow_id}/upload/run/, which uploads and runs in one call. You can also upload a packet first and run it separately. anyformat creates a document packet to hold the document, walks the workflow graph, and writes structured results.

Run lifecycle

Every run moves through a sequence of statuses:

Status	Description
`queued`	Waiting for an available processing slot
`in_progress`	Processing is actively running
`processed`	Processing complete, results available (terminal)
`error`	Processing failed (terminal)
`cancelled`	Processing was cancelled (terminal)

A run only exists once it is triggered, so runs start at queued. Before that, the document packet carries status: not_started. Read a run with GET /v3/runs/{run_id}/. It always returns 200 OK with the status above; results is null until the run is processed, then the results envelope arrives inline on the same read. Poll until the status is terminal, then stop. A processed run looks like this (parse.blocks shortened to one block; field values are strings on the wire):

{
  "id": "069dcc2c-e14c-7606-8000-2ee4fb17b4f9",
  "workflow_id": "0686bb97-8c30-70f0-8000-97669e000eb8",
  "document_packet_id": "069dcc2c-e14c-7606-8000-2ee4fb17b4e1",
  "status": "processed",
  "created_at": "2026-07-01T12:00:00.000Z",
  "updated_at": "2026-07-01T12:02:30.000Z",
  "results": {
    "document_packet_id": "069dcc2c-e14c-7606-8000-2ee4fb17b4e1",
    "verification_url": "https://app.anyformat.ai/review/069dcc2c-e14c-7606-8000-2ee4fb17b4e1",
    "parse": {
      "markdown": "<a id=\"p1_b0\"></a>\n\n# INVOICE\n\n<a id=\"p1_b1\"></a>\n\nInvoice #: INV-001  \nIssue date: 2026-02-20\n\n<a id=\"p1_b5\"></a>\n\n<table>...</table>",
      "text": "# INVOICE\n\nInvoice #: INV-001 ...",
      "parse_confidence": 90.6,
      "layout_confidence": 0.7,
      "blocks": [
        {
          "id": "p1_b1",
          "type": "text",
          "page": 1,
          "bbox": { "x0": 0.114, "y0": 0.132, "x1": 0.322, "y1": 0.210 },
          "parse_confidence": 96.5,
          "layout_confidence": 0.96,
          "content": "Invoice #: INV-001  \nIssue date: 2026-02-20",
          "hyperlinks": [],
          "rows": null,
          "image_base64": null
        }
      ]
    },
    "classifications": [],
    "splits": [],
    "extractions": [
      {
        "split_name": null,
        "partition": null,
        "fields": {
          "invoice_number": {
            "value": "INV-001",
            "value_override": null,
            "verification_status": "not_verified",
            "confidence": 95.0,
            "evidence": [{ "text": "Invoice #INV-001", "page_number": 1 }]
          }
        }
      }
    ],
    "edits": []
  }
}

What the results contain

A run produces one output section per node type that ran. The results envelope has a fixed shape — sections corresponding to nodes you didn’t include come back empty (null or []), so client code can read every key unconditionally.

Section	From which node	Shape
`parse`	the parse node	`markdown` (the whole document, with an `<a id="p<page>_b<n>">` anchor before each block and HTML `<table>` elements), `text`, `parse_confidence`, `layout_confidence`, and `blocks[]` — the same content block by block with page, bbox, and confidences. See Parse. `null` if the workflow has no parse node (rare — parse is required by topology).
`classifications`	classify nodes	Array of `{category, confidence, evidence}`. Empty when no classifier ran.
`splits`	the splitter node	Array of `{name, files, confidence, partitions}` describing the segments. Empty when no splitter ran.
`extractions`	extract nodes	Array of `{split_name, partition, fields, validations}`. Linear workflows produce one untagged entry; branched/split workflows produce one entry per `(split, partition)`. Empty when no extract ran (parse-only workflows).
`extractions[].validations`	the Validate node	Array of `{rule_id, description, severity, status, detail, compared_values, source_fields}`, one per rule, on the extraction entry the rules judged. `status` is `pass`, `fail`, or `inconclusive`. Empty when no Validate node ran.
`edits`	the Edit node	Array of `{file_id, file_name, fields, unmatched_instructions, download_url}`. One entry per file the node filled. Empty when no Edit node ran.
`extraction`	extract nodes (legacy)	Deprecated. Flat `{field_name → ExtractedField}` dict, populated only for linear workflows. Kept for backward compatibility; new code should read `extractions[]`. Will be removed in a future major version.

Each extracted field carries a value, an optional human-supplied value_override, a confidence score (0–100), a verification_status, and an evidence array (source-text snippets + page numbers). See Get run for the full envelope. Read value_override when it is set, and value otherwise.

What the SDKs give you back — both the TypeScript and Python SDKs return a Result from Run.wait(). For linear parse → extract workflows the scalar values are right there: result.fields["name"].value (Python) or result.field("name")?.value (TypeScript). The full envelope — parse markdown, classifications, splits, multi-extraction entries — lives at result.raw in both languages, with Python additionally exposing a typed result.parse view. Expect more typed accessors as the underlying atomic operations stabilise.

Filled forms

An Edit node produces a document rather than data, so its output lands in its own section: edits[], one entry per file the node processed. A collection of five blank forms comes back as five entries. Each entry records which fields were found and what was written into them:

fields: every form field detected, filled or not, in document order. A field carries its printed label, its kind (text or checkbox), the page and bbox it occupies, and the value written into it. Fields the document already carried a value for come back as state: "prefilled"; they are never overwritten, so they always read back with value: null.
unmatched_instructions: the instruction fragments, quoted verbatim, that the linker matched to no field in this document. It covers instructions that found no field, not every reason a value can be missing from the rendered PDF, so treat the filled document itself as the final word.
download_url: a temporary link to the filled PDF.

The download link is short-lived. download_url is valid for 15 minutes from the moment the response was built, and a fresh one is minted every time you read the run. Fetch the PDF when you receive it, or re-read the run for a new link. Storing the URL will leave you with a dead one.

Confidence and evidence

Two signals that travel with most outputs.

Confidence

A 0–100 score indicating how certain anyformat is about a value.

For parse: two document-level scores — parse_confidence (0–100) for how confident anyformat is in the text it read, and layout_confidence (0–1) for how confident it is in the page layout it detected — plus the same pair on every entry of blocks[]. (Technically: parse_confidence comes from the language model’s token log-probabilities, and layout_confidence from the YOLO layout-segmentation model.)
For extractions: a per-field score on each extracted value.
For classifications: a per-verdict score.
For edits: a per-field score with a different meaning from the rest. It grades how surely a filling instruction addressed that field, not whether the value written in is correct. It is raw and uncalibrated, and it is not a probability - treat it as a ranking signal for review, not as a quality score for the filled document.

Evidence

An array of metadata objects showing where a value came from. It’s an array because some values are inferred across multiple spans rather than copied from a single place. Each evidence object has:

The snippet of text the value was derived from
The page number in the document

Evidence is the right signal to surface in any human-review UI — it lets reviewers jump straight to the source. Metadata-sourced values carry a marker. When a field is sourced from a top-level key of the packet’s metadata rather than from the document, evidence[0].text is metadata.<key> (e.g. metadata.customer_reference). Client code can key on this prefix to render metadata provenance differently — or to route the value to a “verified upstream” path — instead of trying to plot a page number that doesn’t exist.

What’s next?

Outputs

Export formats for results — CSV, Excel, JSON, Markdown

Upload and run

Upload a document and start a run in one call

Get a run

The flat read that returns a run with its results inline

Document packets

The unit a workflow runs on

Get started

Nodes

Workflows

Schema & fields

Documents

Outputs & integrations

Health

Billing

Run lifecycle

What the results contain

Filled forms

Confidence and evidence

Confidence

Evidence

What’s next?

Outputs

Upload and run

Get a run

Document packets

​Run lifecycle

​What the results contain

​Filled forms

​Confidence and evidence

​Confidence

​Evidence

​What’s next?

Outputs

Upload and run

Get a run

Document packets

Run lifecycle

What the results contain

Filled forms

Confidence and evidence

Confidence

Evidence

What’s next?