A workflow’s behavior is defined by its steps array. You set it when you create a workflow, update its draft, or create a version. This page is the complete reference for every step type and routing rule. For the end-to-end create → deploy → run lifecycle, start with Create a Workflow.
Each step has a name, a type, an optional config, and a next array that defines where documents flow after the step completes. The same shape is used in request bodies and in the workflow version responses returned by the API.
The simplest useful workflow extracts structured data from a document:
Every workflow starts with a TRIGGER step followed by a PARSE step. After parsing, you can chain any combination of processing, branching, and validation steps.
Each step’s next array defines where documents flow. For most step types, you only need to specify the target step:
For branching step types, each next entry includes a routing field specific to the step type:
The simplest pattern — every step has exactly one downstream step.
Use a CLASSIFY step to route documents to different extractors based on document type. Each next entry’s classificationId must match a classification ID from the classifier’s config.
First, your classifier defines classifications with stable IDs:
Then the workflow step uses those IDs as classificationId values:
Conditions use classification IDs (e.g. "cls_invoice"), not type strings (e.g. "invoice"). IDs are stable across renames — if you rename a classification type from "invoice" to "billing_invoice", the ID stays the same and routing continues to work.
Use a SPLIT step to break a multi-document file into individual sub-documents and route each one by type. The same ID-based routing rules apply as for CLASSIFY.
Use a CONDITIONAL step to route based on extracted data values. Each condition has an id that is referenced by next[].conditionId.
Reference an upstream step’s output in leftOperand (and rightOperand, when comparing to another value) using the {{ stepName.output.value.field }} template syntax — stepName is the producing step’s name, .output.value is the extractor’s value payload, and .field is the field to compare. operation accepts EQUALS, GTE, LTE, IS_NULL, CONTAINS, or NO_OP. See Conditional Steps for the full reference syntax.
Use RULE_VALIDATION to check extracted data against business rules and branch on the result.
See Formulas for the rule expression language and Validation Step for the UI guide.
All processor references (extractor, classifier, splitter) require an explicit version field.
CLASSIFY and SPLIT steps do not support "latest" — you must pin to a specific semver version (e.g. "0.1") or "draft". This is because classification IDs used for routing are tied to a specific version’s config. If a new version is published with different classifications, routing would break silently.
The single entry point for every workflow. Must route to exactly one PARSE step.
Converts the uploaded file into structured content (OCR, text extraction). Must appear immediately after the trigger.
Optionally configure parsing behavior with parseConfig. See Parse Configuration Options.
Runs a published extractor against parsed content. Version is required — "latest", "draft", or semver. Can be created without config — next cannot be set until config is provided, and config is required before deploy.
Routes documents to different downstream steps based on classification. Conditions must reference classification IDs, not type strings. Requires a pinned version — "latest" is not allowed. Can be created without config — next cannot be set until config is provided, and config is required before deploy.
See the Classify and Route pattern above for a complete example.
Splits a multi-document file into sub-documents and routes each one. Same ID-based routing and pinned version rules as CLASSIFY. Can be created without config — next cannot be set until config is provided, and config is required before deploy.
See the Split and Route pattern above for a complete example.
Combines outputs from multiple upstream extract steps. Use mergeOrder to control how overlapping fields are prioritized.
Routes based on extracted data values using if/else logic. See the Conditional Logic pattern above.
For the UI-based version of this step, see Conditional Steps.
Chooses which extractor to run based on formula conditions. Each rule pairs a formula with an extractor reference. The last rule must have formula: "TRUE" as a default catch-all to prevent runtime failures when no other rule matches. Can be created without config — next cannot be set until config is provided, and config is required before deploy.
See Formulas for the expression language and Conditional Extraction Step for the UI guide.
Checks extracted data against boolean rules. Can be created without config — next cannot be set until config is provided, and config is required before deploy. See the Validation pattern above for a complete example.
Sends extraction data to an external HTTP endpoint for validation. Can be created without config — next cannot be set until config is provided, and config is required before deploy.
See External Data Validation Step for more context.
Pauses the workflow for manual review in the dashboard before continuing to downstream steps.
Joins multiple upstream branches before continuing. Use after CLASSIFY or SPLIT branches to wait for all parallel work to complete.
Converts the file format before downstream processing. Use failureBehavior to control whether conversion failures stop the workflow.
Terminal step that delivers results to your webhook endpoint. Must not have next.