Reducto parses documents and extracts structured fields with source context

Reducto supplies APIs for turning documents into application data. Parse reconstructs readable content and layout; Extract returns fields against an intended schema; related endpoints split, classify or edit documents. The buying question is which of those operations your workflow actually needs. Searchable text, an invoice record and a filled form are different outputs, and their errors and charges should be evaluated separately.

01 / ProductSeveral document operations behind one API platform

The Reducto homepage presents parsing, extraction and editing as connected document capabilities. Its r-1 parser is explicitly described as available in preview. That matters for a production decision: evaluate the currently supported model and migration path, rather than assuming a newly promoted model has the same stability commitments as the established service.

The Parse documentation describes structured results that include chunks and blocks, with options for content filtering, page ranges and returned images. A consumer can use the readable content for retrieval while retaining block-level context for inspection. Parsing answers what is on the page and how it is arranged; it does not by itself define the business record the organisation intends to create.

The Extract guide distinguishes schema-based extraction from a schemaless prompt. Schemaless output is useful for exploration, while a defined schema makes production output more consistent. The guide also discusses array extraction for long repeated lists. A statement containing hundreds of transactions requires completeness checks across the list, not just a plausible first transaction.

02 / AudienceA useful component for document-heavy software

Reducto fits engineering teams building software around incoming PDFs, scans, spreadsheets or mixed document packets. Typical jobs include preparing searchable content, populating a draft record from a form, or identifying boundaries within a bundle. It is especially relevant when a reviewer needs to understand why the system selected a value rather than receiving a disconnected JSON result.

It is less suitable as the sole decision-maker for a workflow where an extracted number immediately triggers a payment, approval or irreversible update. In those situations the application needs its own validation and authorization rules. Document extraction can supply candidate values; the surrounding service must decide what evidence is sufficient and which actions require review.

The LlamaIndex blueprint is useful when the larger question is building retrieval and agent applications around documents. The Databricks blueprint covers a broader platform for governed data and AI workflows. Compare the exact output and deployment requirements rather than treating all products with OCR as interchangeable. A parser embedded in developer software and an operational document process can involve very different ownership.

03 / WorkflowA proposed workflow for mixed supplier document packets

Suppose a procurement system receives a bundle containing a supplier form, certificate, price list and supporting correspondence. The proposed goal is to prepare a reviewable draft supplier record, not automatically approve the supplier. This is an illustrative design based on public documentation; Sequenced has not processed a customer packet or measured Reducto's accuracy.

First define the output record and the evidence required for each field. A company name might appear in a letterhead, trading-name field and signature block; those values should not silently overwrite each other. Keep the extracted text, normalized value and reviewer decision distinct. A schema that forces every field to be populated can encourage the system to fill gaps that should remain unresolved.

Decide whether the application needs full-document Parse output, direct Extract output or both for separate purposes. If the only requirement is a structured record, do not automatically add a paid Parse call before every extraction. If the same document also feeds search, retaining parsed content may be justified. The usage and pricing reference states that Extract has no additional parse costs under its current list-rate basis.

Build a test packet with repeated values and ambiguous formatting. For example, place the supplier's billing address on one page and a branch address on another. Define the intended meaning in the field description and inspect the selected evidence. An exact transcription of the wrong address is an extraction failure even if ordinary OCR accuracy appears high.

Use schema-based output for the stable fields and a repeated array for line items. Check counts, totals, dates and currency separately after extraction. If a price list continues across pages, compare the last rows as carefully as the first. The Extract guide warns that long repeated lists can exceed context limits; its array mode provides a documented route to segmentation and merging, which still needs validation against the actual file.

For searchable attachments, review whether repeated headers and page numbers should appear in the retrieval content. Parse's documented filtering can omit selected block types from content while keeping them in block metadata. That is useful when page furniture dominates search matches, but remove only material that is truly redundant. A repeated header could include a version date that is essential to interpreting a policy.

Place uncertain fields in a human review screen alongside the original document. Show whether the value was absent, unreadable, inconsistent or merely unexpected. Those states imply different next actions: request a missing document, inspect a scan, clarify the supplier's identity or correct a mapping. Collapsing them into a single confidence score makes operational follow-up harder.

Finally, test a resubmitted packet and a timeout. Reprocessing the same file should update a draft according to explicit application rules, not create another supplier record. Store job identifiers and input hashes in your own processing record. Separate retries caused by network failures from a deliberate request to run a different parser or schema version, so that costs and evidence remain explainable.

04 / PricingUse the current endpoint tariff rather than an old credit model

The pricing page, consulted 23 September 2026, lists Standard as pay-as-you-go with $150 in introductory usage and up to five Studio seats. Growth and Enterprise are custom priced. Growth lists zero-data-retention agreements and regional endpoints; Enterprise adds private deployment and identity controls. Confirm those contractual options before sending documents whose handling requirements depend on them.

The billing reference says its current standard list prices took effect on 1 September 2026, while negotiated contracts remain authoritative. It distinguishes r-1 Parse from legacy Parse, and documents optional add-ons. Do not transfer a historical credit multiplier into a new estimate. The table below selects common operations; it is not a complete tariff for every mode or document feature.

Cost arithmetic should follow the actual workflow. As an illustration, 10,000 pages at the listed Extract rate of $20 per 1,000 pages would be $200 before credits, taxes or any applicable surcharge. That is our arithmetic, not a quote. Separate other endpoint calls and manual review effort. A lower processing bill is not a saving if more records need correction.

05 / DistinctionsInspectable output is more valuable than a single accuracy claim

Reducto's useful distinction is the relationship between document conversion and structured extraction. An application can use parsing for retrieval while shaping fields for another workflow, with source context helping reviewers investigate disagreements. This is particularly valuable when the document itself is the evidence and the application must preserve a route back to it.

The documentation overview organizes the platform around several document operations rather than one universal response. That encourages a more precise design: classify a packet when routing is the problem, split it when boundaries matter, and extract only the fields needed by the next step. Evaluate each operation independently. An accurate classification does not prove that every row in the extracted table is complete.

06 / QuestionsPreview status and contractual processing conditions need resolution

The first open question is whether r-1 is available and suitable for the intended account and workload. Its public tariff and preview label coexist. Obtain the supported version, fallback route and change policy before relying on it for a time-sensitive process. Preserve the parser and schema version with each result so a later change can be investigated against earlier behaviour.

The second is how documents, returned assets and logs are retained in the selected plan and region. Pricing lists stronger processing agreements in higher tiers; do not infer those agreements from the presence of an API key. We have not validated private deployment, inspected a negotiated contract or performed an extraction benchmark. For the proposed supplier workflow, the pilot should establish correction effort and completeness on the actual forms, including scans and changed layouts.

07 / DecisionChoose the operation that matches the record you need

Reducto merits evaluation when document interpretation is a core component of a software product. Begin with a defined output contract, representative files and a way to inspect disagreements. Choose Parse, Extract or a combination according to downstream use, then calculate cost from the selected endpoints. The strongest result is a document process whose omissions and uncertainties remain visible to the people accountable for the resulting records.