job_id that represents the parsed document. You can pass this job ID to subsequent Extract or Split calls using the jobid:// prefix, which skips re-parsing and uses the cached result. This saves both time and credits when you need to run multiple operations on the same document.
The jobid:// protocol
After parsing a document, the response includes ajob_id:
jobid://:
jobid://, it retrieves the cached parse result instead of processing the document again. Any parsing options you include in the request are ignored since the document was already parsed.
Common chaining patterns
Parse → Extract
The most common pattern. Parse once, then run one or more extractions with different schemas:Parse → Split → Extract
For documents with distinct sections that need different extraction schemas:Parse → Classify → Extract
When you need to determine document type before choosing an extraction schema:Multiple job IDs
Extract also accepts a list of job IDs, which combines the parsed content from multiple documents into a single extraction context:Supported endpoints
| Endpoint | Accepts jobid:// | Notes |
|---|---|---|
| Parse | Yes | Reprocesses with different settings |
| Extract | Yes | Single ID or list of IDs |
| Split | Yes | Single ID only |
| Edit | No | Requires actual document URL |
Credit savings
When you usejobid://, you only pay parse credits once regardless of how many subsequent calls you make:
| Without chaining | With chaining |
|---|---|
| Parse (4 credits) | Parse (4 credits) |
| Extract #1 (4 + 2 credits) | Extract #1 (2 credits) |
| Extract #2 (4 + 2 credits) | Extract #2 (2 credits) |
| Total: 16 credits | Total: 8 credits |