Pipelines

A Pipeline chains the features you already configured (Splitters, Collections, flows, agents, Matchers, Inspectors, Fillers and Buckets) into one end-to-end process that you draw on a canvas. You send in one document; the Pipeline carries it through every step and delivers the result where you want it.

Each node on the canvas points at a feature that already exists. The Pipeline does not copy its configuration: when you improve a flow's fields or an Inspector's checks, every Pipeline that uses it picks up the change. What the Pipeline adds is the order: which step receives the document, which runs follow, and where the output goes.

• A bundle has to be split, each document extracted by its own flow, and the results checked together
• Extracted data should go on to an agent, a Matcher comparison or an Inspector checklist without anyone clicking through
• You want one inbox address or one API call that runs the whole process, not one per feature
• The result should land in Slack, Teams, Google Chat, an automation platform or an inbox as the final step

If a single flow with its own webhook, email or Bucket export already does the job, you don't need a Pipeline. Features keep working on their own.

Every canvas starts with one Entry node. You add the rest from “Add node”, which groups them by the stage they play: “Receive & route”, “Extract”, “Process & check” and “Deliver”.

When a node is selected, “Add node” dims the kinds that can't follow it and wires the new node automatically. Picking a flow also suggests the Matchers, Inspectors and Fillers whose inputs already expect runs of that flow (“Connected to this flow”), added pre-wired. Agent nodes need agents, which are enabled per organisation on request.

1. 1Open “Pipelines” in the sidebar and click “New Pipeline”. Give it a name and, optionally, a description.
2. 2The canvas opens with its Entry node. Select it and choose how documents arrive (see Sources below).
3. 3Click “Add node”, pick a step, then pick which of your features to use. Or drag from the handle on the right of a node onto another node to connect them.
4. 4Select a node to open its panel: its linked feature, what it receives from and sends to, and its settings (the Bucket write's field mappings, the Output's destination, the Matcher's benchmark input).
5. 5Fix anything listed under “Fix these before running” until the chip reads “Ready to run”, then click “Save”.
6. 6Click “Run pipeline” and upload a document to test it.

The canvas has “Tidy up” (automatic layout), undo and “Redo”, “Duplicate”, shift-click and shift-drag multi-selection, and an “Overview” minimap on larger graphs. Scroll to pan, ⌘ + scroll to zoom, and Delete removes the selection. Unsaved edits are kept in your browser and restored if you come back.

Instead of placing nodes by hand, click “Draft with AI” on the canvas and describe the process in a sentence, for example: “When invoices arrive: extract them with the Invoices flow, run the control checklist, and store the rows in the Invoices DB bucket.”

• The assistant reads the features your organisation already has, designs the graph and validates the connections, then lays the draft on the canvas.
• If a step needs a feature you don't have yet (a flow, Splitter, Inspector or Bucket), the node is marked “New” and its panel shows what will be created. “Create this feature” (or “Create N features”) builds them for real; review them and save.
• “Keep” accepts the draft; “Discard” restores the canvas as it was before. A draft replaces every node and connection on the canvas, so you are asked first if one already exists.

Drafting does not run anything.

Select the Entry node to see its three sources.

The email trigger, the “Pipeline ID” and the “Active” switch are also on the “Settings” tab. Inactive pipelines reject new executions from every source.

An Output node sends everything its upstream steps produced. Pick a destination in the node's panel:

{
  "pipeline_id": "…",
  "execution_id": "…",
  "pipeline_name": "Invoice intake",
  "original_filename": "document.pdf",
  "outputs": [
    {
      "node": "Invoices",
      "node_type": "flow",
      "output": { "invoice_number": "…", "total": 1250.5 }
    }
  ]
}

The panel shows an “Example payload” built from the upstream flow's fields; the real one carries the extracted values. Files in the output arrive as time-limited links. The chat destinations show up to eight key fields from the first upstream result.

A feature keeps its own behaviour inside a Pipeline: a flow still fires its own webhook, email, Bucket export, Cleaner, human review and linked agent. The canvas points out where that overlaps with what you drew.

• A Bucket write into the same Bucket the upstream flow already exports to would store the rows twice.
• A webhook Output after a flow that already sends a webhook would post the result twice.
• An email Output after a flow that already emails its results would send a second email.

These appear as warnings under “Worth a look — it will still run”. They never block a run. Cards also carry small marks for what the feature delivers on its own (“Webhook”, email recipients, “Human review”, agent delivery), listed in the node panel under “Also delivers to”.

A flow node's panel also shows “Also used in”: the Collections, Splitters and other Pipelines that depend on the same flow, so you know what else an edit to it affects.

“Run pipeline” and the API refuse a graph that breaks any of these; the canvas badges the node at fault.

• Exactly one Entry node, with no inbound connections. No cycles and no self-connections.
• Every other node needs an inbound connection and a linked feature (an Output needs a recipient or a webhook URL).
• Flows, Splitters and Collections take one document from one source: the Entry, a Splitter, or (for flows) a Collection.
• Every connection into an Inspector or Filler needs an input slot; a Filler can't receive two connections into the same slot.
• At most 50 nodes per Pipeline.

Matchers, Inspectors and Fillers (and any node fed by more than one source) wait until everything upstream has finished, then run once. After a Splitter, each matched document becomes its own branch, and the steps after it run once per branch.

Each document that enters a Pipeline creates one execution. The “Executions” tab lists them with the document, time, source, sender, duration and status.

Open an execution to see the canvas as it ran, tinted by node status, with progress (“X of Y nodes done”) and live updates. Each node shows Pending, Waiting, Queued, Running, Completed, Failed, Skipped or Cancelled, with a chip per branch after a Splitter. Select a node and use “View result” to open the run, split, match, inspection or fill it produced.

“Cancel execution” stops the rest of the graph: nodes that haven't started are cancelled, while feature runs already in progress finish on their own.

Copy the ID from “Pipeline ID” on the Settings tab. Start an execution by posting the document as multipart file (or as JSON with file_base64 and filename):

curl -X POST https://run.tavnit.io/api/pipelines/PIPELINE_ID/execute \
  -H "X-API-Key: $TAVNIT_API_KEY" \
  -F "file=@document.pdf"

{
  "success": true,
  "execution_id": "…",
  "pipeline_id": "…",
  "org_id": "…",
  "status": "running"
}

A definition that isn't executable returns 400 with validation_errors; a 402 means your organization can't start new work right now (contact the Tavnit team); an inactive Pipeline returns 400. Follow progress on the Executions tab. To stop an execution:

curl -X POST https://run.tavnit.io/api/pipelines/executions/EXECUTION_ID/cancel \
  -H "X-API-Key: $TAVNIT_API_KEY"

Cancelling an execution that already finished returns 409. Authentication and error handling are the same as the rest of the REST API.

Deleting a Pipeline removes it and its canvas; past executions keep their records. See User roles.