Skip to main content
A pipeline parses one document, then runs up to 10 more Extract, Split, Tables or Charts steps on the parse, from one request. Use a pipeline when every document of a kind gets the same steps, and always when your organization deletes results on their first read. The steps start once the parse completes and run side by side, and the parse decides how the pipeline ends: Each step is still a job of its own endpoint, with its own id, status and result.

Run a pipeline

This example parses a 10-K, extracts the company’s name and reads its tables, then reads the Extract step’s result once the pipeline ends:
wait is the polling helper from Jobs and results. A pipeline always runs async: POST /pipeline returns 202 with the pipeline_id at once, and takes no async field.

Write the steps

config.step is the parse, always {"type": "parse", "config": {...}}, with POST /parse’s options in config. config.children lists up to 10 steps that read it, each with a type of extract, split, tables or charts and that endpoint’s options in config. Leave children out to run the parse alone. Each step takes its config inline, never a config_id. Steps don’t feed each other: each one reads only the parse. To extract each topic that a Split step finds, run Extract on the pipeline’s parse_id with the topic’s pages as page_range once the Split step ends. To reuse a pipeline, save its whole config as a pipeline config and send its config_id instead. The API reference lists every field.

When a pipeline is refused

POST /pipeline checks the whole pipeline before anything runs. If any part is refused, no step runs and nothing is billed. For example:
  • a step’s config is invalid, there are more than 10 children, or a step needs an endpoint your organization hasn’t turned on, such as Tables or Charts: 400;
  • the parse itself is refused, for example because the file can’t be read: the status POST /parse would return;
  • your API key’s credit limit doesn’t cover the parse together with its extract and split steps: 402.

Follow a pipeline

GET /pipeline/{pipeline_id} (client.pipeline.get) returns the pipeline’s status, which takes the same values as a job’s. GET /pipeline/{pipeline_id}/result (client.pipeline.get_result) lists each step’s id and status, but no step output. Partway through, a pipeline’s result looks like this:
Here usage adds up the two steps that have completed, the parse and the Extract step, at 80 pages each.

How a pipeline ends

Once every step has ended, the pipeline ends as its parse did: A step that fails doesn’t stop the other steps, so check each step’s status in the result. DELETE /pipeline/{pipeline_id} (client.pipeline.cancel) cancels a pipeline that is still queued or processing, with its unfinished steps. Those steps never complete and aren’t billed. A step that already completed keeps its result.

Use a pipeline when results are deleted on first read

Some organizations have each result deleted the first time it’s read, which makes the order of your calls matter outside a pipeline. In a pipeline, the parse stays available to the pipeline’s steps until every one of them has ended, even if you read the parse’s result first. Reading GET /pipeline/{pipeline_id}/result doesn’t count as reading any step’s result.
Each step’s result, the parse’s included, can still be read only once. A second read returns 410, so save what you read the first time.

Billing and retention

Each step costs what its endpoint costs once it completes, and the pipeline adds no charge of its own. See Pricing. The pipeline and its steps expire together, counted from when the pipeline ends. If the parse step sends storage.save: false, for example, the pipeline and every step expire 24 hours after the pipeline ends.