Your first document,
one request away.

Quick start

Create a workspace, obtain configured trial credits or purchase a credit pack, and create a processing API key. Upload a document, retain the returned job ID, then poll for a terminal status.

# Run on your server. Configure the deployed API URL.
export YULOGO_OCR_BASE="https://api.yulogo.com/v1"

curl --fail-with-body -X POST "$YULOGO_OCR_BASE/documents" \
  -H "Authorization: Bearer $YULOGO_OCR_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -F "file=@invoice.pdf" \
  -F "mode=balanced" -F "languages=eng,tam"

# The 202 response contains id and status/result URLs.
# Poll GET /jobs/{id} until a terminal state.
curl --fail-with-body "$YULOGO_OCR_BASE/jobs/$JOB_ID" \
  -H "Authorization: Bearer $YULOGO_OCR_KEY"

curl --fail-with-body "$YULOGO_OCR_BASE/jobs/$JOB_ID/result" \
  -H "Authorization: Bearer $YULOGO_OCR_KEY"

Authentication

Developer requests use Authorization: Bearer YOUR_API_KEY. Create and revoke keys in the dashboard. The full key is revealed once; save it in your server’s secret manager.

Browser dashboard requests use a secure workspace session. Processing keys cannot manage administrator credentials, workspace settings or billing. Never embed an API key in a website, mobile bundle or public repository.

Idempotent submission

Provide an Idempotency-Key header for every upload. Reuse the same key when retrying the same file and processing options. The service returns the existing job without a second reservation or charge. Reusing a key with a different payload returns a conflict; generate a new key for a new submission.

Public API endpoints

All paths above are relative to /v1. The deployed backend exposes generated OpenAPI documentation at /docs; consult it for the complete request shape and validation limits.

Extraction schemas

POST a name and executable label definition. Built-in types are invoice, challan and roll_sheet. Custom fields match literal visual labels; they do not infer missing content. General JSON Schema keywords and external references are not supported.

{
  "name": "Roll weight",
  "definition": {
    "type": "custom",
    "fields": [{
      "name": "weight",
      "labels": ["Weight", "எடை"],
      "type": "decimal",
      "required": true
    }]
  }
}

The response returns an id. Include it as schema_id in your next document upload, or create and select a schema directly in the playground.

Input formats

PDF, JPEG, PNG and TIFF are validated by actual contents. File, page-count, pixel and decompression limits apply. Password-protected, malformed or unsupported documents return actionable errors. Arbitrary URL ingestion is disabled.

Job lifecycle and errors

queued → processing → completed
                    → completed_with_review
                    → failed
                    → cancelled

Poll every two seconds initially and back off for longer jobs. The progress response reports completed and total pages. Do not infer an accuracy score from job progress. Keep the job ID if your application’s polling deadline expires.

Error responses contain a machine-readable code and message. Worker failures are reported on the job. Completion webhooks remain disabled until delivery, signing, replay protection and network safety have been verified; use polling for the initial integration.

Results and source coordinates

Results include document and page IDs, text blocks, reading order, extracted fields, table cells, polygons, raw and normalized values, issues, review status, model details, timings and billable usage. Availability depends on the page evidence and configured adapter.

Coordinates use original raster pixels with the origin at the top left. X increases right, Y increases down. PDF pages are rasterized at 150 DPI. Page width and height define the coordinate canvas. A polygon is an ordered list of [x,y] points. Coordinates are mapped back from OCR rotation to the original page.

// Illustrative field; actual results come from your document.
{
  "name": "invoice_number",
  "raw_value": "INV-0241",
  "normalized_value": "INV-0241",
  "evidence": {
    "page_id": "page-id",
    "polygon": [[110, 240], [350, 240], [350, 275], [110, 275]]
  },
  "review_status": "review_required"
}

Read uncertainty as a request to review

Recognition confidence, image quality and validation status are different signals. Confidence is not calibrated correctness. An unreadable value is null; missing characters are not invented from context. Preserve ambiguous dates, currencies and units until reviewed.

Human corrections are stored separately with timestamps. JSON export preserves the automatic result; correction history is available through the dashboard review endpoint. UTF-8 text exports recognized text; CSV exports detected tables. XLSX and searchable PDF are deferred pending Unicode and alignment validation.

Recognition capabilities

The initial adapters target printed English and printed Tamil using configured OCR engines. Availability of an engine does not establish a benchmark. Verify each language, document type and scan condition separately against ground truth.

The AetherOCR Paddle profile uses PP-OCRv6 tiny, small and medium for English. Tamil uses an explicit Tesseract language route. Paddle fields can carry line-level evidence; these readings require review of the full highlighted line. Optional UVDoc and PaddleOCR-VL readings remain separate review candidates.

Handwritten English, handwritten Tamil, mixed handwriting, cursive, signatures, overwritten values and difficult handwritten tables have no verified support claim. Optional heavier adapters must pass compatibility, license and independent quality checks before they are enabled.

Quality diagnostics and selective non-generative processing can flag or improve some scans. Severe blur, glare, faded marks and cropped text can remain unreadable. Rescan guidance accompanies detected issues. No generative enhancement is used to invent visual evidence.

Three processing modes

Fast uses the lightweight path. Balanced adds selective quality checks and preprocessing. Accuracy permits additional bounded processing for difficult pages. Model routing depends on configured engines. Mode-specific prices are visible on the pricing page; latency and accuracy comparisons await measurements.

Credits, reservations and quotas

Pricing and trial allowance are backend configuration. Credits are integers; currency amounts use minor units. Jobs reserve credits before processing. Final reconciliation charges eligible processed pages at the configured mode rate and releases unused reservations.

Blank pages and failed pages are not billable. Partial jobs charge eligible pages only. Job retries and duplicate payment events do not create additional charges. Exporting a result has no processing charge. Repeated idempotent uploads reuse their job; cross-document cache billing is deferred.

Razorpay starts in test mode. The backend creates the order and verifies its signature and authoritative captured-payment status before credits are added. A browser success message alone cannot grant credits. Check the ledger after checkout.

Limits include upload size, pages per document, rate limits, available credits and workspace spending cap. Review your current limits through GET /usage.

Security and retention

Every document query, result, storage path and download is scoped to the authenticated workspace. Files are stored in S3-compatible storage and processed by restricted background workers. Public marketing pages have no access to private results.

Configure retention in workspace settings. Deletion covers originals, previews and live results; active jobs must not recreate deleted documents. Storage and database backups follow the deployment’s separately configured retention and restoration policy.

External document providers are disabled by default. Enabling one requires explicit customer configuration and transfer consent. Customer data is not used for training without consent and reviewed labels. Avoid logging document contents or credentials in your integration.