PDF to Text Conversion API: OpenParser at $1 per 1,000 Pages

OpenParser is a hosted API built around PaddleOCR-VL-1.6, an open-weight vision-language model that claims strong performance on document parsing benchmarks. According to the builder's announcement post, they could not find a reliable production provider, so they built one and opened the endpoints publicly. The result is a parse endpoint that returns typed blocks, markdown, and table HTML, plus a separate extract endpoint that fills a JSON schema you define.

The pricing story

As of June 2025, comparable layout-aware OCR services such as Reducto have been listed at several dollars per 1,000 pages. Verify current pricing directly with each provider, as rates change frequently and vary by volume, document type, and feature tier. OpenParser lists at $1 per 1,000 pages for the layout lane, with 1,000 pages free to start. Verify current pricing and free-tier terms at openparser.dev before committing, as terms may change. A playground lets you upload a document and inspect parsed blocks before writing a single line of code.

For operators who process invoices, contracts, forms, or scanned documents at volume, this changes the math. But before accepting any pricing comparison at face value, check each provider's current published rates directly, because API pricing shifts often and the tiers that apply to your volume may differ from list price.

A note on accuracy. PaddleOCR-VL-1.6 claims strong benchmark results, but no independent accuracy figures are publicly available for messy scans, handwritten fields, or non-English text as of this writing. For use cases where extraction errors carry financial or legal consequences, run your own accuracy tests on a representative sample before committing to production.

One caution, stated upfront

This is a solo-built early product. There are no published SLAs, uptime guarantees, data processing agreements, or enterprise support tiers. The use cases below involve invoices, contracts, and resumes, all of which contain sensitive personal and commercial data. Before sending real documents to any hosted API, confirm the provider's data retention policy, deletion practices, and any applicable compliance certifications such as SOC 2, GDPR, or HIPAA. OpenParser does not currently publish these. For teams with strict reliability or compliance requirements, treat this as a prototyping tool until the service matures, and have a fallback provider identified. A multi-day outage or a change in the builder's priorities would be a real operational problem for any workflow wired into production.

How teams can use it

Finance analyst

What for: Extract line items and totals from supplier invoices into a structured format for reconciliation.

Outcome: Each invoice becomes a clean JSON record with vendor name, date, line items, and total, ready to paste into a spreadsheet or accounting tool.

Reliability note: Because OpenParser carries no SLA, do not route this into a live AP system without a manual review step and a fallback process for outages.

Build it in 5 steps:

1. Sign up at openparser.dev and grab a free API key.
2. Upload a sample invoice in the playground and confirm the table blocks and field values are parsed correctly, including any multi-page tables.
3. Use the /extract endpoint with a simple schema listing the fields you need, such as vendor, date, line items, and total. Pass the parsed output to Claude or GPT-4o via their respective APIs to fill the schema, as this connection is made manually rather than through a built-in integration.
4. Call the OpenParser REST API from an automation platform such as Make or Zapier using their HTTP or webhook modules. Test your specific workflow before deploying to production, as no official OpenParser connector has been published for these platforms.
5. Review the JSON output in a shared spreadsheet and flag any low-confidence blocks for manual check.

Where it gets complex: Building a full AP automation pipeline with approval routing or ERP write-back needs a developer or a dedicated AP automation tool.

Operations lead

What for: Convert stacks of scanned delivery receipts or proof-of-delivery forms into searchable records.

Outcome: Hundreds of scanned forms become a searchable table of delivery dates, reference numbers, and signatures without manual typing.

Reliability note: For high-volume operations workflows, identify a backup OCR provider before going live. A solo-operated service with no published uptime guarantee is a single point of failure.

Build it in 5 steps:

1. Create a shared folder in Google Drive where drivers or warehouse staff drop scanned PDFs.
2. Call the OpenParser /parse endpoint from Make or Zapier using their HTTP module. Test the connection thoroughly before treating it as production-ready.
3. Review the markdown and block output in the OpenParser console to confirm layout is captured correctly.
4. Add an /extract step with a schema for the fields you need, such as delivery date, order number, and recipient.
5. Write the extracted JSON rows into a Google Sheet or Airtable base for daily review.

Where it gets complex: High-volume batch processing with error handling and retry logic is easier to manage with a developer setting up the queue.

HR manager

What for: Parse submitted resumes and application forms into a consistent structured format for initial review.

Outcome: Each PDF resume becomes a structured record with name, contact, work history, and skills, reducing time spent reading raw files.

Legal note: Automated resume screening that extracts and filters on fields such as years of experience or key skills may implicate EEOC guidance and, in some jurisdictions, algorithmic hiring laws such as New York City Local Law 144. Consult legal counsel before using any automated screening output to make or influence hiring decisions. Do not treat this workflow as a compliance-ready ATS replacement.

Reliability note: Resume data is sensitive. Confirm OpenParser's data retention and deletion practices before uploading candidate files.

Build it in 5 steps:

1. Upload a small batch of sample resumes in the OpenParser playground to check parsing quality on your actual document formats.
2. Define an extract schema with fields like name, email, most recent employer, years of experience, and key skills.
3. Pass the parsed output from the /parse endpoint to Claude or GPT-4o via their respective APIs to fill the schema. This connection is made manually through each model's API.
4. Store the JSON output in an Airtable base with one row per candidate.
5. Use the structured output to organize candidates for human review before any screening decision is made.

Where it gets complex: Connecting this to an ATS or automating bulk uploads from a careers portal needs light developer work or an ATS with a native API.

Small business owner

What for: Pull key terms from signed contracts and lease agreements into a simple tracker.

Outcome: A running log of contract start dates, renewal dates, and key obligations without reading every PDF manually.

Reliability note: Contract data is commercially sensitive. Review OpenParser's data handling practices before uploading signed agreements, and keep local copies of all source documents.

Build it in 5 steps:

1. Upload a contract PDF to the OpenParser playground and check that clauses and tables are captured accurately.
2. Define a short extract schema with fields like party names, start date, end date, renewal notice period, and monthly value.
3. Send each new contract through the /extract endpoint, passing the parsed output to your preferred LLM via its API to fill the schema.
4. Log the output into a Google Sheet with one row per contract.
5. Set a calendar reminder based on the renewal date column so nothing auto-renews unnoticed.

Where it gets complex: Automated alerting, clause-level risk flagging, or multi-party redlining needs a dedicated contract management tool or legal tech specialist.

How to apply this

1. Run a free accuracy test first. Upload ten real documents from your actual workflow into the OpenParser playground at openparser.dev. Check whether tables, multi-page layouts, and any handwritten or non-standard fields parse correctly before spending any money or time on integration.
2. Confirm data handling before uploading sensitive files. Contact the OpenParser team and ask directly about data retention, deletion timelines, and any compliance certifications. If you cannot get a written answer, do not upload invoices, resumes, or contracts until you can.
3. Verify pricing and compare it yourself. Check the current published rates at openparser.dev and at each competitor's pricing page on the same day. Do not rely on any third-party comparison, including this article, for final budget decisions.
4. Test your automation connection with dummy data. If you plan to use Make or Zapier, build the HTTP module connection using sample files and confirm the output is correct before connecting it to a live email folder or Drive.
5. Identify a backup provider before going live. Because OpenParser is a solo-operated service with no published SLA, name an alternative OCR provider you could switch to within a day if the service goes down. Keep your schema definitions and sample documents saved locally so a migration is straightforward.