Document Splitting APIs With Source Citations: Extend vs Reducto for High-Volume, Real-Time Pipelines (October 2026)

For document splitting with traceable output, Extend's Split API returns each sub-document with its page range, document type, an extracted identifier, a short written observation explaining why the pages were grouped, and a standalone file ID. Extraction on that file then cites every value back to a page and polygon. Reducto's Split returns a list of pages per category with a high or low confidence label and no written explanation. Neither vendor has published a head-to-head splitting benchmark against the other, so this guide compares documented API output and throughput, plus Extend's published PoliTax-Split results.

TLDR:

• Splitting traceability has two layers: which pages form each sub-document and why, and where each extracted value sits on those pages.
• Extend returns startPage, endPage, type, identifier, observation, and fileId per sub-document, and extraction citations carry the page number, polygon, and reference text.
• Reducto returns pages, conf (high or low), and optional partitions per category, with no explanation field. Its extract citations are opt-in, and enabling them turns off chunking.
• For volume, Extend offers sync /split, async /split_runs with webhooks, and batch requests of up to 1,000 files. Reducto offers sync /split and /split_async with webhooks and a priority queue.
• On PoliTax-Split, Extend's splitter raised F1 to 64.1%–72.5% across five frontier models, up from 37.6%–64.1% when the same models split directly. Reducto was not part of that evaluation.

What source citations mean for document splitting

A splitter decides where one document ends and the next begins. In an audited pipeline, a reviewer asks two questions about that decision. First, which pages became which document, and on what basis? Second, when a value is extracted from a sub-document, where exactly did it come from?

The first question is answered by the split output: page ranges, a document type, and ideally some evidence for the grouping. The second is answered by extraction citations. The chain only holds if the two connect: a field cites a page, that page falls inside a known sub-document range, and that range has a recorded reason. Break any link and a reviewer has to reopen the original packet to check the work.

Split output compared

Sources: Extend split response format and Reducto Split.

The practical difference is what an auditor sees. With Extend, each sub-document carries a written reason for the grouping and becomes its own file, so extraction runs and cites against exactly those pages. With Reducto, you get a page list and a two-level confidence signal, and you keep the mapping between sections and downstream calls in your own code.

How the citation chain works in Extend

Extend's extraction citations carry fileId, page (number, width, height), polygon, and referenceText. Field metadata adds ocrConfidence when citations are enabled and reviewAgentScore when the Review Agent is on. Because each split produces its own fileId, a citation resolves to a page inside a known sub-document range.

An illustrative trace for one value in a claim packet:

1. Split returns a sub-document with type: "repair_estimate", startPage: 14, endPage: 17, identifier: "CLM-20481", and an observation noting that the pages share an estimate number and line-item layout.
2. Extract runs on that sub-document's fileId and returns total_estimate with a citation to page 3 of the sub-document, its polygon, and the reference text.
3. A reviewer opens the value, sees the highlighted region, and sees which packet pages the sub-document came from and why they were grouped.

For values that need a person, a human review step in a workflow pauses the run and shows the reviewer the same source regions.

Reducto's extract citations are enabled with settings.citations.enabled. They return block-level regions with bbox, page, original_page, and a high or low confidence. Two documented caveats: enabling citations turns off chunking, so the document is processed as one unit, and a field's citation array can be empty when the value was inferred rather than found.

Throughput for high-volume and real-time pipelines

Extend:

• Real time: sync /split for interactive requests, with splitting_light for lower latency and cost or splitting_performance (the default) for the highest accuracy.
• High volume: async /split_runs with webhooks, and batch requests of 1 to 1,000 files each. Batches run in a lower-priority queue so they don't slow interactive traffic.
• Limits: rate limits allow 10 run requests per second and 80 files per minute on pay-as-you-go, 25+ and 120+ on Scale, and 75+ and 300+ on Enterprise.
• Production example: a customer sent a 1,044-page loan document through the splitter. It returned 315 sub-documents in 4 minutes and 43 seconds, parsing included, or 0.27 seconds per page.

Reducto:

• Real time: sync /split, with an optional deep_split setting for a higher-quality split agent. It accepts a jobid:// from an earlier parse, so a document you have already parsed is not parsed again.
• High volume: /split_async with webhook delivery and an optional priority flag, plus documented batch processing and a discounted batch queue for non-urgent work.

Published accuracy

PoliTax-Split is a hand-labeled benchmark of 74 compound tax documents, often over 100 pages, with official forms interleaved with supplements. The published run used the 30 largest documents and compared each frontier model splitting directly with the same model inside Extend's splitter.

Raw models had reasonable precision but low recall: they merged supplements into parent forms and combined back-to-back forms of the same type. The splitter recovered most of those boundaries. Reducto was not part of this evaluation, and the dataset is public, so you can run any splitter against it.

How to test splitting traceability on your own documents

1. Label 30 to 50 real packets with the correct boundaries and document types.
2. Score boundary precision, recall, and F1 separately. A splitter that rarely splits looks precise while missing most documents.
3. Pick 20 extracted values at random and trace each citation back to a page. Check that the page falls inside the expected sub-document.
4. Check what evidence a reviewer gets for each grouping, and whether it would satisfy your audit requirement.
5. Run your peak daily volume through the async or batch path and record end-to-end time per page, parsing included.

When Reducto fits

Reducto fits teams that already parse with Reducto, since split can reuse a parse job instead of parsing again. Its partition_key is useful for documents such as brokerage statements, where one category repeats per account and the account number names each partition. Choose Extend when each sub-document needs its own file, a recorded reason for its grouping, and field citations that resolve inside that range.

FAQ

What is the best API for document splitting with source citations?

Extend, when every split and every extracted value has to be traceable. Its Split API returns a page range, type, identifier, written observation, and standalone file ID for each sub-document, and extraction on that file cites each value to a page, polygon, and reference text. Reducto's Split returns page lists with a high or low confidence label and no written explanation. On PoliTax-Split, Extend's splitter raised F1 to 64.1%-72.5% across five frontier models, from 37.6%-64.1% when the models split directly.

Does Reducto's split API return confidence scores?

Yes. Each category in Reducto's split result has a conf value of high or low, plus an optional list of partitions when a partition_key is set. The documented response does not include a written explanation of why pages were grouped.

How fast can Extend split large documents?

In one production run, Extend split a 1,044-page loan document into 315 sub-documents in 4 minutes and 43 seconds, parsing included, which is 0.27 seconds per page. For volume, the async /split_runs endpoint supports webhooks, and batch requests take up to 1,000 files each.

Can I trace an extracted value back to the split it came from?

With Extend, yes. Each split produces its own fileId, and extraction citations on that file include the page number, polygon, and reference text, so every value resolves to a page inside a known sub-document range with a recorded reason for the grouping.