Key facts
| API compatibility | Drop-in /v1/chat/completions with JSON mode and function calling (live) |
| Extraction output | JSON mode for typed field records with source references |
| Validation | Function-calling tools for totals, dates, identifiers and duplicates |
| Models | 30+ models behind one endpoint, route extraction and reconciliation separately |
| Migration | Base URL and model-name change; OCR engine and pipelines stay as they are |
| Pricing | Flat monthly plans with unlimited fair-use usage on self-serve |
| OCR | Dedicated OCR engine in your pipeline; image endpoints are coming soon |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
TL;DR
- Keep the OCR engine; change the model client and add structured extraction.
- Use JSON mode for field records with source references and confidence.
- Validate arithmetic, identifiers and duplicates in tools, not in the model.
- Route exceptions to a review queue with the source page attached.
- Evaluate on labelled documents and re-run when templates change.
How it works, step by step
- Centralise the model client so base URL, key and model names come from configuration.
- Keep OCR output intact — text, page numbers and confidence — as the input to extraction.
- Define JSON schemas per document type with fields, types, required flags and source references.
- Set the client to https://api.plugsky.com/v1 and map extraction and reconciliation tasks to different models.
- Implement validation tools and run them on every extracted record before filing.
- Run a shadow batch over labelled documents and compare field accuracy and exception routing with the current process.
- Cut over behind a flag, monitor correction rates, and keep the previous provider path for rollback.
Try it yourself
Open the JSON schema validator for LLM tools →
Where compatibility fits an OCR pipeline
OCR workflows already have an engine that produces text; what they often lack is structured extraction and reliable validation. That is exactly what an OpenAI-compatible endpoint provides: JSON mode to turn text into typed records, function calling to run checks, and streaming for interactive tools. No new SDK, no bespoke response parsing.
Plugsky's chat completions endpoint is live with JSON mode and function calling. Image generation and files endpoints are coming soon, so keep OCR and bulk document handling in your pipeline and use the model layer for understanding the text.
Structured extraction and validation
Define a schema per document type and demand strict output: values, types, source references and a per-field confidence. Then validate in code. Rejecting malformed records is better than repairing them, because a silently corrected field is an unauditable edit to a financial or legal record.
- Arithmetic: recompute totals, tax and line items and compare with printed values.
- Identifiers: validate tax numbers and account codes with checksum or master-list tools.
- Duplicates: check document number plus amount plus date before filing.
- Provenance: store the OCR page reference on every field for reviewer verification.
Scale, review and exceptions
Volume work suits tiered routing: small models for straightforward extraction, stronger models for ambiguous layouts and reconciliation. With 30+ models behind one endpoint, changing the routing for one document type is a configuration edit. Keep batch processing in your own scheduler; the files and batch endpoints are coming soon.
Build the review queue as a first-class part of the system, not an afterthought. Reviewers should see the source page beside the extracted fields and be able to correct, accept or reject in one pass; their corrections become evaluation data. Track straight-through rate and field-level accuracy per document type, re-evaluate when templates or suppliers change, and deploy in a region that satisfies your document handling policy, including on-prem when scans cannot leave the network.
Honest comparison
| Aspect | Plugsky | Staying on OpenAI | Template OCR tools |
|---|---|---|---|
| Client change | Base URL and model names | None | Vendor-specific |
| Structured output | JSON mode with source references | Available | Template-bound |
| Validation | Function-calling tools in your code | Same pattern | Limited rules |
| Adaptability | New layouts via prompts and schemas | Same | Template rework |
| Pricing | Flat monthly with unlimited fair use on self-serve | Per-token | Per-page or seat |
Frequently asked questions
Do we still need an OCR engine?
Yes. Plugsky does not provide a live OCR endpoint. Keep your engine, then use the compatible chat endpoint for structured extraction, validation and routing. Image endpoints are coming soon.
Why JSON mode instead of free text?
Typed records feed downstream systems directly and can be validated field by field. Free text requires parsing, which reintroduces the ambiguity you are trying to remove.
How do we stop bad records being filed?
Validate every field against schema and business rules, and file only records that pass. Send failures to a review queue with the source page rather than correcting them automatically.
Can different document types use different models?
Yes. Route simple invoices to small models and complex contracts to stronger ones. 30+ models sit behind one endpoint, so routing is per-type configuration.
Is streaming useful here?
For interactive review tools, yes — reviewers see extraction progress. Batch processing does not need streaming and can run with lower overhead.
How do we start without disrupting the current process?
Shadow-run the new extraction on labelled documents in parallel, compare field accuracy and exception routing, then cut over behind a flag with rollback in configuration.
Can it run on-prem?
Yes. Plugsky supports region-locked cloud planes plus VPC, on-prem and air-gapped deployment, so scanned documents can remain inside your network.