--- question: How do I run a pipeline from Nexus, Python or HTTP? kind: task via_web: available via_cli: available via_python: available via_api: available via_config: na ref_web: System › Jobs › Run now ref_cli: abi run script ref_python: Pipeline.run ref_api: POST /pipelines/{name} prereq: You need a pipeline whose `run` is filled in, in a module that runs. See [Create a pipeline](/v2/capabilities/build/knowledge-graph/creating-a-pipeline). Durable runs (Nexus, `/api/workflows`, `get_workflow`) need ABI 3.x in a NATS project. next: - /v2/capabilities/build/pipelines/schedule-a-pipeline - /v2/capabilities/build/pipelines/monitor-runs - /v2/capabilities/build/workflows/monitor-and-cancel-a-run --- > **You are reading the v2.x docs (engine modules). New projects use v3.** [Read this page in v3](/capabilities/build/pipelines/run-a-pipeline) · [Migrate from 2.x to 3.0](/capabilities/upgrade/migrate-to-3) # Run a pipeline Running a pipeline calls its `run(parameters)`. It returns an `rdflib.Graph`, and the usual class also inserts that graph into the triple store before returning. Every tab below ends in the same call; they differ in where it runs, and in whether the run is recorded: - **A direct call** (a script, an agent tool, `POST /pipelines/...`) runs `run` in process and records nothing. - **A durable run** (ABI 3.x, in a NATS project) starts the published workflow `pipeline.` by name. One replica of the module runs it, once (no retry: a second attempt would insert twice), and the run shows in System › Jobs with its input and output. The output is the graph as `{"format": "text/turtle", "triples": n, "data": ""}`, without `data` above 60 KiB. ## Web UI ABI 3.x, in a NATS project only. ABI 2.x and 3.x without NATS have no System app and no durable runs: use the CLI, Python or REST steps on this page. ### Open the pipeline Open **System** from the Nexus sidebar, then the **Jobs** tab. Pick **Workflows** in the kind filter: each pipeline shows under its published name, such as `pipeline.items_pipeline`. Click it. ![System app on the Jobs tab, filtered](/abi/Screenshot_System_Jobs.png) *System › Jobs: jobs and workflows, with their schedules and recent runs.* ### Start it Click **Run now**. The form is built from the parameters model; **JSON** switches to an editor. Click **Run**. The start is written to the audit log, and the input is checked against the parameters model before anything is sent. ### Follow the run The run shows in **Runs**. Its **Steps** tab has the one step, `run`, and its **Result** tab the triple count and the Turtle. See [Monitor runs](/v2/capabilities/build/pipelines/monitor-runs?via=web). The System app is for platform super admins only. ## CLI ### Write a script ```python title="scripts/run_items.py" from my_module.pipelines.ItemsPipeline import ( ItemsPipeline, ItemsPipelineConfiguration, ItemsPipelineParameters, ) graph = ItemsPipeline(ItemsPipelineConfiguration()).run(ItemsPipelineParameters()) print(f"{len(graph)} triples") ``` ### Run it with the engine ```bash abi run script scripts/run_items.py ``` `abi run script` loads the engine (configuration, services, modules), then runs the file. Arguments after the path reach the script as `sys.argv`. On ABI 3.x in a NATS project the broker has to be up (`abi dev up` or `abi stack start`). This is a direct call: it is not recorded as a run. The command is [`abi run script`](/user-guide/reference/cli#abi-run-script). ## Python ### Call run ```python from my_module.pipelines.ItemsPipeline import ( ItemsPipeline, ItemsPipelineConfiguration, ItemsPipelineParameters, ) pipeline = ItemsPipeline(ItemsPipelineConfiguration()) graph = pipeline.run(ItemsPipelineParameters(filter="open")) ``` The pipeline reads its services from the module, so call it where the engine is loaded: an agent tool, a workflow, a [module job](/v2/capabilities/build/pipelines/schedule-a-pipeline), or a script run with `abi run script`. Outside the engine, `ABIModule.get_instance()` raises "Module … not initialized". ### Start a durable run ABI 3.x, in a NATS project. Start `pipeline.` by name, from the module itself or from another one: ```python items = self.get_workflow("pipeline.items_pipeline") # the module's own pipeline out = await items.run({"filter": "open"}) print(out["triples"]) run = await items.start({"filter": "open"}, idempotency_key="items-open-2026-10-31") ``` From another module, get the proxy with `self.engine.get_workflow("", "pipeline.items_pipeline")`, with the module declared as a dependency. `run.status()`, `run.steps()` and `run.cancel()` are on [Monitor and cancel a run](/v2/capabilities/build/workflows/monitor-and-cancel-a-run?via=python). To rebuild the graph from the output: `Graph().parse(data=out["data"], format="turtle")`. ### Give it to an agent `as_tools()` returns the pipeline as LangChain tools. An agent adds them in its `New()`; see [Give it tools](/v2/capabilities/build/agents/give-it-tools). ## REST API ### Find the route The engine mounts one route per loaded pipeline whose `run` takes a Pydantic parameters model: `POST /pipelines/`, so `ItemsPipeline` is `/pipelines/items_pipeline`. The API's `/docs` page lists them under **Pipelines**. There is no route that lists pipelines. ### Call it ```bash curl -s -X POST "http://localhost:9879/pipelines/items_pipeline" \ -H "Authorization: Bearer $ABI_API_KEY" \ -H "Content-Type: application/json" \ -d '{"filter": "open"}' ``` The body is the parameters model as JSON (`{}` when it has no fields). The token is the engine's `ABI_API_KEY`, not a Nexus login: see [Authentication](/api/authentication). The response is the graph as Turtle: ```json {"format": "turtle", "data": "@prefix ..."} ``` ### Or start a durable run ABI 3.x, in a NATS project. `POST /api/workflows/{module_id}/pipeline./runs` on Nexus starts any module's pipeline as a recorded run: ```bash curl -s -X POST "http://localhost:9879/api/workflows/my_module/pipeline.items_pipeline/runs?wait=60" \ -H "Authorization: Bearer $ABI_API_KEY" \ -H "Content-Type: application/json" \ -d '{"filter": "open"}' ``` With `?wait` (0 to 120 seconds) and a run that ends in time, the answer carries its `status` and `result`; without it, `202` with the run, `QUEUED`. The key is the engine's `ABI_API_KEY` (or a super admin's session), and the start is audited. The options (`Idempotency-Key`, 422 on a refused input) are on [Run a workflow](/v2/capabilities/build/workflows/run-a-workflow?via=api). ## Config Not applicable. `config.yaml` has no key that runs a pipeline. To run one on a schedule, see [Schedule a pipeline](/v2/capabilities/build/pipelines/schedule-a-pipeline).