Story

Most products that touch PDFs or images quietly rebuild the same thing: a hacked-together “router” that picks which OCR/vision API to call, normalizes the responses, and prays the bill is sane at the end of the month.

DocsRouter is that layer as a product: one stable API that talks to multiple OCR engines and vision LLMs, lets you route per document based on cost/quality/latency, and gives you normalized outputs (text, tables, fields) so your app doesn’t care which provider was used.

It’s meant for teams doing serious stuff with documents: invoices/receipts, contracts, payroll, medical/admin forms, logistics docs, etc., who are either stuck on “the OCR we picked years ago” or are overwhelmed by the churn of new vision models.

Right now you get a REST API, simple SDKs (coming soon), a few pluggable backends (classic OCR + newer vision models), some basic routing policies, and a playground where you can upload a doc and compare outputs side by side.

I’d love feedback from HN on two things:

1- If you already juggle multiple OCR/vision providers, what does your homegrown router look like, and what would you need to trust an external one?

2 - Would you prefer this or use the LLM/OCR providers directly, with the possibility of changing the provider every so often?

Demo and docs are here: https://docsrouter.com