Choosing an OCR API: a developer's checklist

Integrating a document API is a long-term commitment: it ends up in your retry logic, your alerting and your incident runbooks. The model's accuracy is what the marketing page discusses, and it is rarely what costs you a weekend.

The EasyInvoiceOCR API is coming soon

To be clear before you read further: our own API is not yet available. It is announced but not operational, it does not currently accept requests, and this article is not a pitch for it. The checklist below is what we would want you to hold any vendor to, ourselves included when the endpoint does open.

Look for these in the documentation

If any of these is absent from the public docs, assume it is absent from the product. Documentation omits features that exist far less often than vendors imply.

• A stable error envelope with machine-readable codes, not prose messages that change between releases.
• Idempotency keys on upload, so that a retry after a timeout cannot create a duplicate document.
• Explicit rate-limit headers and a documented Retry-After, rather than an undocumented 429.
• Versioning via a header or a path segment, with a written deprecation policy.
• Cursor pagination on list endpoints; offset pagination silently skips and repeats rows under concurrent writes.

Test the failure paths first

Upload a corrupt PDF, a password-protected file, a zero-byte file and a blank page before you test the happy path. How an API fails tells you far more about the engineering behind it than how it succeeds, and you will spend more of your operational life in those branches than you expect.

Ask where the document goes

The operational checklist and the privacy checklist are the same conversation. Retention, training on customer data and sub-processors all belong in the integration decision, not in a later review.