DocRead: OCR API for scanned documents

An OCR API is a web service that takes a scanned page or a photo and returns its text. OCR stands for optical character recognition. Your application sends a file over HTTP, the service reads it, and the response carries the text in a form your code can store, search or pass to another system.

Teams use an OCR API when documents arrive as images: supplier invoices, signed forms, bank statements, delivery notes, medical reports and old archives. A person can read those files on a screen. Software needs OCR to turn the pixels into characters.

DocRead does that job and adds a check that most OCR services leave to you. It reads every scanned page twice, with two independent readers from two different vendors, and compares the printed values. A value that only one reader writes comes back as a dispute.

The market sorts into three groups. Knowing which one you need saves most of the evaluation work.

DocRead sits between the first two groups. It returns the text of each page and, through a second call, the fields of your own JSON schema. It ships no review screen. Your application receives the disputes and decides what a person should see.

OCR engines fail in five common ways.

Silent errors. An engine reads 1,280.00 as 1,230.00 and returns the wrong figure with a high confidence score. Nothing in the response marks it, so the mistake travels into your accounts. A second independent reader catches this class of error, because two engines from two vendors rarely misread the same digit in the same way.

Tables and reading order. A multi column invoice can come back with its lines shuffled. A price can end up beside the wrong article even when every character is correct.

Scan quality. Skewed phone photos, faxes, stamps over text and low resolution all reduce accuracy. A test set built only from clean PDFs tells you little about real traffic.

Handwriting. Handwritten fields behave differently from print. DocRead has no published handwriting benchmark, so test it on your own forms before you rely on it.

Meaning. Plain OCR returns characters. It cannot tell you which of three dates on a page is the due date. Structured extraction handles that job. A section further down this page covers it.

The request below sends a file to the read route. The service key travels in the Authorization header.

curl -X POST https://your-docread-host/read \
  -H "Authorization: Bearer $DOCREAD_KEY" \
  -F [email protected]

You can also send a signed URL instead of the file. DocRead fetches it only from hosts your deployment allows, and any other host returns HTTP 403.

curl -X POST https://your-docread-host/read \
  -H "Authorization: Bearer $DOCREAD_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://files.example.com/signed/invoice.pdf", "filename": "invoice.pdf" }'

The response below is an illustration with invented values. The field names are the real ones.

{
  "filename": "invoice.pdf",
  "mime": "application/pdf",
  "sha256": "9f2c...",
  "textLayer": "ocr",
  "pages": ["Invoice 2041\nTotal due 1,280.00 EUR\n..."],
  "disputes": [],
  "settled": [],
  "readOnceOnly": [],
  "usage": {}
}

Three fields tell you how far to trust the reading.

• disputes lists, page by page, the contested values and the lines each reader wrote.
• settled lists the pages a third reader reread.
• readOnceOnly lists the pages only one reader could read, so those pages had no comparison.

An empty disputes and an empty readOnceOnly mean every critical value on every page had two readers behind it. Your code can process the file without review. Any other file can go to a person with the exact values in doubt.

The read route returns text. The structure route returns fields from that text and a JSON schema of your own.

curl -X POST https://your-docread-host/structure \
  -H "Authorization: Bearer $DOCREAD_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Invoice 2041\nTotal due 1,280.00 EUR\nDue 30 June 2026",
    "schema": {
      "type": "object",
      "properties": {
        "invoiceNumber": { "type": "string" },
        "totalDue": { "type": "string" },
        "dueDate": { "type": "string" }
      }
    }
  }'

The response holds fields, a confidence value per field and usage. Confidence takes one of three values.

A field the document does not state comes back as null. DocRead never computes or corrects a value, so a total that does not match its lines stays as printed. Your own business rules can then catch the mismatch.

A confidence score describes how the extraction read the text. It does not measure whether the source text was read correctly. Paired reading protects the text before the schema step runs.

The error codes are explicit, so your integration can treat each failure differently: a bad request, a missing key, a file that is too large, an unreadable document or a provider that failed.

The DocRead bench dated 25 October 2026 used two sets of scanned pages.

A wrong amount is a money figure in the reading that the page does not print. We rank that metric first because a wrong amount passes silently. Born digital PDFs took the text layer path: on 29 pages that path produced 0 wrong amounts and 0 missed amounts.

These two sets hold 31 pages. Test your own documents before you rely on these figures.

A vendor's accuracy figure describes the vendor's test set. Run your own, and use the same set for every service you compare.

Build the set from your real traffic and include the hard cases: skewed phone photos, low resolution faxes, mixed handwriting and print, tables that cross a page break, stamps over text, and new layouts from known senders. Choose about fifty varied documents, including your worst scans.

Score these metrics, in this order.

Character accuracy alone hides the failures that matter. A reader can score 99% on characters and still change one digit in every total.

OCR pricing usually runs per page, and the same job can land at very different prices depending on what the provider counts. Compare complete jobs, including retries and review time.

DocRead has no public price list, because deployments are set up per client. Its cost follows a simple logic.

• A file with its own text makes no model call.
• A scanned page makes two model calls.
• A disputed page makes a third call when the deployment names a third reader.

The usage field of every response gives the calls and tokens of each model, and their cost at public prices when the profile holds them. You can see the cost of each document as it runs.

Document pipelines carry contracts, invoices and medical data, so ask every OCR vendor these questions. Here are the DocRead answers.

Retention. DocRead keeps no document. The log holds one line per request: method, path, status, time and page count. The body of a document, its name and its text are never logged.

Access. Every route except /health needs a service key.

Signed URLs. The service fetches a document only from hosts on the allowed list.

Antivirus. A scan route checks a document before you read it.

Model providers. A scanned page goes to the two model providers your profile names, so their data terms apply to that page. A file that takes the text layer path leaves your deployment at no point.

DocRead runs as an HTTP service behind your reverse proxy, or as a library inside your own process. An idle deployment uses no memory.

These checks apply to any OCR API, and they catch most production failures.

• Send a document your pipeline should refuse, and confirm your code handles the error.
• Decide what happens to a page in readOnceOnly, because it had no second reader.
• Store the sha256 of each file, so a resend can be recognised.
• Set a timeout that fits a long scan, because each page makes model calls.
• Log the disputes per document, because a sudden rise usually means a new layout or a worse scanner.
• Keep the model usage per document, so cost changes show up early.

DocRead fits teams whose documents carry amounts or medical values that must stay exact, and who already have an application to plug it into. Accounting flows, insurance files, form intake and medical records are the natural cases.

It fits less well if you want a finished review screen, a public self serve signup, or a price list today. It offers none of those. Language coverage and handwriting accuracy have no published figures, so include both in your own test.

Good input costs less than any later correction, so give suppliers and staff simple capture rules.

A review step should focus on the documents that carry a flag.

1. Let clean documents pass on their own.
2. Send only flagged values to a person.
3. Show the page image next to the value.
4. Record each correction.
5. Sample a share of the clean documents each month.

Those corrections show where your documents fail, so your process improves over time.

Teams often ask whether a general language model can replace OCR. It can read many pages well. The risk lies in how it fails.

A wrong word in a summary is a small problem. A wrong amount in a payment run is a serious one, so match the method to the cost of an error.

1. Which fields trigger a payment or a decision?
2. What does one wrong value cost?
3. How many documents arrive each month, and at what peak?
4. Who reviews exceptions today?
5. How long must originals be kept?
6. Which suppliers send the worst scans?

The answers tell you which values need strict checks and how much review your team can absorb.

1. Pick one document type with a clear owner.
2. Run the service next to your current process for a few weeks.
3. Compare results by hand on a sample.
4. Switch the clean documents to automatic handling.
5. Add the next document type.

The comparison gives your finance team evidence to review.