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
configis 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 /parsewould 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:
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. ReadingGET /pipeline/{pipeline_id}/result doesn’t count as reading any step’s result.
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 sendsstorage.save: false, for example, the pipeline and every step expire 24 hours after the pipeline ends.