Each provider has its own shape
Different request formats, different field names, different confidence semantics. Every consuming system learns all of them, and relearns when one changes.
DocSenseOCR Orchestration & Document Extraction Platform
One document API. Any OCR provider behind it.
DocSense puts a single, stable contract in front of Azure, Gemini and Textract — routing each document to the right provider, falling back when one fails, and returning the same normalised response whichever one answered.
Overview
We do not build OCR engines. We orchestrate them.
The recognition itself is a commodity, and it is improving faster than any single vendor can be relied on. What is not commodity is the layer around it: choosing a provider per document, handling failure, and turning whatever comes back into one predictable shape your systems can consume.
That layer is DocSense. Your applications integrate once, and never again when the provider landscape changes.
- Category
OCR Orchestration & Document Extraction Platform - Role
Horizontal capability, called by other platforms and by your own - Providers
Azure, Gemini and Textract today; new ones added by configuration - Starting with
Indian identity and KYC documents, extending to other structured documents - Deployment
Cloud-ready or on-premise
Provider-agnostic
SolTech does not claim proprietary recognition. DocSense is
deliberately an abstraction: the value is the single contract, the routing, the
fallback and the normalised output — not the engine underneath, which you should be
free to change.
The problem
Integrating an OCR provider directly is a trap.
One provider is a single point of failure
A timeout or an outage stops document processing entirely, because there is no second path and nothing that knows how to take it.
No one document type suits one engine
Accuracy varies by document. Cost and latency vary too. Without routing, you pick one compromise and live with it across everything.
How it works
Request in, universal response out.
The caller sends documents and a token. Everything after that is the platform's problem, not theirs.
Authenticate
Token validated for the calling system, and the user where the upload is manual.
Log and correlate
The request is logged and given a correlation id carried through every component.
Classify
Document type detected, or taken from the caller where it is already known.
Route
Rules pick the provider by document type, priority and any system override.
Extract
A provider adapter calls out and returns raw output. Adapters hold no data and no credentials of yours.
Normalise
Output mapped to standard groups and fields, with values normalised and confidence attached.
Validate and return
Required-field and parsability checks run, then the response goes back with its metrics recorded.
Capabilities
What DocSense does
One API contract
- Classification API — what is this document?
- Extraction API — pull these fields from it
- Universal OCR API — do both in one call
- Input validation and schema enforcement
- Standardised request and response handling
Rule-based routing
- Provider chosen per document type
- Priority set by accuracy, speed or cost
- Automatic selection, or a provider the caller forces
- System-specific overrides where one document must always go one way
- Rules held as configuration, not code
Provider integration
- Azure, Gemini and Textract adapters
- Provider-agnostic internal interface
- Failover to an alternate provider, retry on transient failure
- Usage tracking per provider — latency and token consumption
- A new provider is an adapter and a rule, not a rewrite
Universal response
- Provider output mapped to standard groups and fields
- Values normalised to one format
- Confidence scores carried through
- Required-field and parsability validation
- Callers never branch on which provider answered
Security
- Token-based access control with expiry and revocation
- System-level identity for partner and machine callers
- Optional user-level identity for manual uploads
- Provider adapters perform no authentication and touch no database
Observability
- Request and response logging
- Provider interaction logged separately
- Errors captured against the correlation id
- Processing time, provider latency and token usage
- Volume and usage tracking per calling system
Scenarios
The ways it actually gets used.
The same platform serves an automated back-end pipeline and a person uploading a scan at a branch counter.
- Automatic routing
One document arrives, the type is detected, and the rules pick the provider. - Forced provider
The caller names Azure or Gemini explicitly, and routing is overridden where permissions allow. - Manual upload
A user uploads through the interface under user-level authentication, with case-wise tracking and summaries. - System to system
Fully automated, high-volume, non-interactive integration. - Provider failure
The primary provider fails, an alternate takes over, and the switch is logged and traceable. - Error handling
Authentication failures, invalid input, unsupported file types, provider timeouts and internal errors all return a standardised error response.
Architecture principles
The abstraction is the product.
Everything below is in service of one goal: your systems should not know or care which engine read the document.
Stable contract, moving parts
Providers change, get better, get cheaper or get replaced. The API your systems integrated against does not.
No provider lock-in
Because routing is configuration, swapping or adding a provider is a commercial decision rather than an engineering project.
Adapters are dumb by design
A provider adapter only makes the outbound call. It validates no tokens and reaches no database, so the blast radius of a provider integration stays small.
Traceable end to end
One correlation id links the request, the routing decision, the provider call and the response — so any extraction can be explained afterwards.
In the SolTech ecosystem
The reading layer under the portfolio.
DocSense is used directly, and by the platforms that need a document turned into data before they can act on it.
- InstaDocs — extracts index metadata from documents as they are captured, so classification is not purely manual.
- Insight Underwrite — supports document scrutiny and quality checks on submitted proposal and medical paperwork.
- PayLifPro — reads submitted requirement documents against the payout case.
- EzBilling One — supports mandate capture from the signed mandate image.
- SuTra — receives extracted fields as facts, so a document can drive a rule decision.
What changes operationally
Integrate once
One contract for every document type and every provider, now and later.
No single point of failure
A provider outage becomes a fallback rather than a stoppage.
Tune per document
Route for accuracy where it matters and for cost where it does not.
Costs you can see
Latency and token usage tracked per provider and per calling system.
Which documents are still being keyed by hand?
Tell us the document types and the volumes, and we will show you what routing them through one contract looks like.