Provider landscape¶
Docgate is provider-neutral, but provider-neutral does not mean every service has the same API. OCR services, vision models, document parsers, and local engines differ in input granularity, billing, output structure, privacy, and execution model. Docgate must model those differences instead of hiding them behind a list of brand names.
This page separates what works now from what belongs on the adapter roadmap. It is a compatibility map, not a claim that every listed service is currently integrated or equally suitable for every document.
The landscape was reviewed against official documentation on 31 August 2026. Provider models, limits, APIs, and prices change; applications must still pin their own configuration and pricing provenance.
What works now¶
| Route | Examples | Current integration |
|---|---|---|
| Native OCR API | Mistral OCR | Built-in MistralOcrProvider |
| Native vision API | Anthropic Claude | Built-in AnthropicProvider |
| OpenAI-compatible vision | OpenAI and endpoints that accept Chat Completions image_url data URLs |
Built-in OpenAICompatibleProvider |
| Local/private/custom | Any Python function or existing SDK | Built-in CallableProvider |
OpenAI compatibility is a wire-protocol route, not a provider guarantee. A host is compatible with the current adapter only if its selected model accepts PNG data URLs in Chat Completions and returns text in the expected response shape. Model availability, request limits, authentication, and pricing still belong to the operator.
Ecosystem map¶
Managed OCR and document AI¶
These services have document-specific APIs and deserve native adapters rather than being forced through a generic vision prompt.
| Provider or product | Relevant shape | Docgate route |
|---|---|---|
| Google Document AI | OCR processors, layout, handwriting, quality signals | Native adapter planned |
| AWS Textract | Text, forms, tables, queries, signatures, async jobs | Native adapter planned |
| Azure Document Intelligence | OCR, layout, tables, selection marks, Office inputs | Native adapter planned |
| Mistral OCR | Native page/document OCR with Markdown output | Built in |
| ABBYY Cloud OCR SDK | Commercial OCR API and container deployment | Plugin candidate |
| Nanonets | OCR and document extraction workflows | Plugin candidate |
| Mindee | OCR and structured document APIs | Plugin candidate |
| Mathpix | Async document OCR, especially STEM/math content | Plugin candidate |
Document parsing APIs and frameworks¶
These tools often return Markdown, chunks, layout, tables, or coordinates. Docgate should govern their cost and data movement without becoming a competing parser or silently discarding their richer output.
| Provider or project | Relevant shape | Docgate route |
|---|---|---|
| LlamaParse | Hosted document parsing and extraction | Plugin candidate |
| Reducto | Structured JSON, OCR, tables, figures, positions, confidence | Plugin candidate |
| LandingAI ADE | Markdown, grounded chunks, splitting, async parse jobs | Plugin candidate |
| Unstructured | Local, self-hosted, or hosted document partitioning | Extractor plugin candidate |
| Docling | Local structured conversion, tables, layout, Markdown/JSON | Extractor plugin candidate |
| Marker | Local document-to-Markdown/JSON conversion | Extractor plugin candidate |
Vision-model APIs and runtimes¶
Vision-language models are useful as a quality fallback when ordinary OCR is weak or when a page contains layout-dependent text. They should not all require bespoke Docgate classes.
| Route | Examples | Integration strategy |
|---|---|---|
| Native APIs | Google Gemini, Anthropic Claude | Native adapter where authentication or request semantics differ materially |
| OpenAI-compatible hosted endpoints | Together AI, Fireworks AI, Groq, Z.ai, NVIDIA-hosted NIM, compatible Hugging Face routes | Reuse OpenAICompatibleProvider when the selected endpoint passes conformance tests |
| Self-hosted OpenAI-compatible runtimes | vLLM, NVIDIA NIM | Reuse the protocol adapter; record a private/local trust zone explicitly |
| Local runtime with distinct image schema | Ollama | Small native plugin planned |
| Model-specific prediction APIs | Replicate and similar model catalogs | Plugin or CallableProvider; model input/output schemas vary |
Useful protocol references include Together vision inputs, Groq vision, NVIDIA NIM VLM APIs, vLLM multimodal serving, and Ollama vision.
Local OCR engines¶
Local execution is essential for private documents, offline workloads, and a cheap first pass. Heavy model packages remain optional so installing Docgate does not download a model or GPU stack.
| Engine | Relevant shape | Docgate route |
|---|---|---|
| Tesseract / OCRmyPDF | Mature local OCR and searchable-PDF workflows | First native local plugin target |
| PaddleOCR | Multilingual OCR and document pipelines | Plugin target |
| EasyOCR | Lightweight multilingual OCR | Plugin candidate |
| Surya | OCR, layout, reading order, and tables | Plugin candidate |
| docTR | Local deep-learning text detection and recognition | Plugin candidate |
All of these can be wrapped today with CallableProvider. Native plugins add
configuration, capability declarations, usage accounting, and conformance
tests; they do not make the engines core dependencies.
The provider contract must evolve by capability¶
The current Provider protocol deliberately covers the smallest useful unit:
PNG pages in, text pages out. That is enough for OCR-to-vision fallback, but it
cannot accurately describe every provider above. Before the provider API is
frozen, Docgate will add explicit capability metadata for:
- accepted inputs: page image, selected-page PDF, or whole native document;
- selection granularity: page or document;
- execution: synchronous, asynchronous job, provider batch, or local process;
- outputs: text, Markdown, confidence, coordinates, layout, and tables;
- pricing unit: page, token, pixel, compute time, credit, or caller-defined;
- limits: bytes, pixels, pages, images per request, concurrency, and region;
- governance: local/external trust zone, deployment region, and declared retention controls;
- accounting: estimated cost versus provider-reported usage.
This distinction is operationally important. A whole-document parser cannot be presented as page-selective unless its adapter constructs and hashes a local selected-page payload. An asynchronous Textract-style job cannot be treated as a synchronous image call. A token-billed vision model cannot use a fake per-page price without making the receipt misleading.
Adapter priorities¶
The build order is based on production reach and architectural coverage, not brand popularity:
- Define capabilities and a provider conformance kit.
- Ship local Tesseract/OCRmyPDF and PaddleOCR plugins.
- Ship native AWS Textract, Azure Document Intelligence, and Google Document AI adapters.
- Add Gemini and Ollama routes, while validating common OpenAI-compatible hosts through conformance fixtures instead of duplicating adapters.
- Add one async structured-parser integration, then use that contract for LlamaParse, Reducto, LandingAI ADE, and similar plugins.
- Publish optional community plugin packages through Python entry points.
Every adapter must preserve the same Docgate guarantees: planning stays local, budgets are hard ceilings over declared estimates, provider failures remain visible, cache identities include non-secret model/configuration identity, and unread pages never become empty strings.