PDF Extraction API Guide: Use Cases, Limits, OCR & Tables

Tuko's PDF API lets a developer delegate request-time PDF parsing to Tuko instead of installing and operating the parser, rendering, OCR, and table-extraction dependencies inside their own application. The caller uploads a PDF, Tuko processes it temporarily on the server, and the caller receives a JSON response.

That is useful, but the current public endpoint is a developer utility—not a managed enterprise outsourcing service. The distinction matters when deciding which business workflows should depend on it.

OpenAPI 3.0 and Swagger integration

Tuko publishes a machine-readable OpenAPI 3.0.3 document at /openapi.json. It describes both multipart endpoints, allowed values, response models, HTTP errors, and realistic examples. Use the interactive Swagger UI to inspect schemas or send a test request without writing code first.

Developers can import the JSON contract into tools that support OpenAPI 3.0 for client generation, API testing, request collections, or typed integration scaffolding. Generated code still needs application-level timeouts, validation, error handling, and human review because the contract describes the HTTP interface—not a service-level guarantee.

Realistic use cases for the current public API

Verify extracted values against the source PDF before making financial, legal, medical, or operational decisions.

Does this outsource PDF processing to Tuko?

Technically, yes. Your application sends the PDF to Tuko over HTTPS. Tuko's server runs the parser and optional OCR, then returns the result. Your application does not need to package the native PDF and OCR runtime itself.

Commercially and operationally, not yet. The public endpoint is not currently documented as a managed service with an SLA, reserved capacity, a DPA, supported API versions, incident commitments, or enterprise support.

Where the current API fits—and where it does not

Step-by-step API integration

curl -X POST \
  -F "[email protected]" \
  -F "format=markdown" \
  https://www.tuko.my/api/v1/pdf/extract

curl -X POST \
  -F "[email protected]" \
  -F "format=markdown" \
  -F "pages=1-5" \
  -F "ocr=auto" \
  -F "lang=eng+msa" \
  https://www.tuko.my/api/v1/pdf/extract

curl -X POST \
  -F "[email protected]" \
  -F "pages=2-6" \
  https://www.tuko.my/api/v1/pdf/tables

HTTP errors to handle

Operational and privacy considerations

An API call is a third-party document transfer. The implementation processes the request temporarily and does not intentionally save the PDF, but the public endpoint does not currently provide a contractual deletion guarantee, data-processing agreement, data-residency commitment, or service-level agreement. Do not send confidential, personal, regulated, medical, legal, or financial documents unless your organization has explicitly approved that processing arrangement.

For any integration, add request timeouts, validate file type and size before upload, control request rates, record failed and skipped page lists, retain source-page references, and require human verification where extraction errors could cause harm. A self-hosted pipeline or a documented managed provider is the safer choice when contractual controls are mandatory.

For a visual explanation of the document signals, read how to identify scanned and searchable PDFs. For workbook exports, see how separate Excel worksheets preserve table structure.