Solutions
There is no API yet — here is what does exist
If you are evaluating this for an integration, the honest answer comes first: the HTTP API is not built. No endpoint accepts requests and no key is issued.
The OCR API page describes the planned interface. It accepts no requests.
The problem
This page used to list five endpoints, a bearer token and example requests. None of it was callable, which made it documentation for something that did not exist. It has been removed rather than qualified.
What does work today runs entirely in the browser: recognition, field extraction, review and export, with no server round trip for the document itself. If that fits where your users already are, it is usable now.
How it works
What is actually available
The browser tools. Invoice OCR, the PDF invoice parser, Receipt to Excel and Image to Excel all run client-side and export Excel, CSV or JSON. There is no integration step and no key.
- Recognition and extraction run in the visitor's browser
- Exports are produced client-side as .xlsx, CSV or JSON
- No document is uploaded to be read
What is not available
The HTTP API. There is no endpoint, no authentication, no sandbox, no SDK and no webhook delivery. API access is not included in any current plan and is not billed.
What is being designed
Submit a document, check its status, retrieve the structured result, list submissions, delete one. The design goals are idempotent submission, a stable machine-readable error envelope and explicit rate-limit headers. None of it is implemented.
No date is being promised
Announcing a date before the service is built and tested would be a guess, and an integration plan should not be built on a guess.
How to evaluate any document API
The checklist we would want you to hold us to — error envelopes, idempotency keys, rate-limit headers, versioning and cursor pagination — is written up in the developer guide, and it applies to every vendor including us.