OCR API for Developers
send files, image URLs, or Base64 payloads and receive normalized OCR text, Markdown, page blocks, and Processing Credit usage.
Endpoint: POST /api/v1/ocr
A developer path from test file to production OCR
This page summarizes the developer workflow: create a Developer API Key, submit OCR input, receive normalized output, monitor usage, and keep billing predictable with Processing Credits.
Multiple input types
Use multipart file upload, image_url, or Base64 payloads from your backend.
Normalized response
Receive success, text, markdown, pages, elapsed_ms, and usage.credits.
Processing Credit metering
Processing Credits are checked before OCR and deducted after successful recognition.
Usage logs
Valid-key calls record status, latency, Processing Credits, source type, IP, and user agent.
Developer OCR options
Pick the workflow that matches your integration depth.
| Capability | OCR API Automated | Web OCR Manual review | DIY OCR service Build and operate |
|---|---|---|---|
| Integration | |||
| Server-side calls | |||
| Developer API Key authentication | Custom | ||
| File, URL, Base64 inputs | File and URL | Custom | |
| Operations | |||
| Usage logs | History | Custom | |
| Processing Credit billing | Custom | ||
| Error mapping | Custom | ||
Example API response
The response contract is designed for direct product integration.
Success body
success: true, data.markdown, data.text, data.pages, elapsed_ms, usage.credits
Page blocks
pages[0].blocks can include type, text, confidence, bbox, and page metadata.
Errors
401 invalid key, 402 insufficient credits, 429 limit exceeded, and structured OCR errors.
OCR API for Developers FAQ
Authentication, billing, and response behavior.
Build with the OCR API
Create a key, send a test request, and monitor usage while your integration scales.