Document Processing

Every document endpoint under /lmkit/v1 shares one pipeline: a file goes in (PDF, Word and the MS Office family, HTML, EML and MBOX email, images), pages come out as structured text, with OCR filling in whatever is scanned rather than digital. This guide covers that shared pipeline and the endpoints that operate on whole documents; PDFs get their own toolbox, the analysis endpoints theirs, and the splitting, classification, and extraction stages built on this substrate form the Intelligent Document Processing category.

1One input contract everywhere#

Document endpoints accept the document three ways: inline plain text, base64-encoded file content, or a file id from POST /lmkit/v1/files/upload. Upload once and reference the id across calls when the same document flows through several endpoints (convert, then extract, then summarize), so the bytes cross the wire once. Format detection is automatic, and GET /lmkit/v1/file-information reports what the server sees in a file (and the thumbnail endpoint lists every renderable extension) rather than making you guess.

OCR is part of ingestion, not a separate step you orchestrate: pages without a digital text layer are recognized automatically where the endpoint enables it, and recognition output is screened so photographic noise does not become "words". OCR behavior is configured in the OCR section.

2Conversion: Markdown as the interchange#

POST /lmkit/v1/document-to-markdown turns any supported document into Markdown, the format every downstream consumer (models, diff tools, humans) reads natively. This is the workhorse endpoint: RAG pipelines that manage their own chunking, migration jobs that free content from Office formats, and any flow that wants "the text, with structure, without the container". Tables, headings, and reading order survive the trip; page boundaries are preserved so downstream references can still say "page 4".

For the reverse direction, POST /lmkit/v1/image-to-pdf packs images into a PDF (the assembly chapter covers it), and the OCR overlay makes that PDF searchable.

3Rendering and inspection#

• POST /lmkit/v1/document-thumbnail renders any page of a document or image as an image, for previews and pickers.
• POST /lmkit/v1/document-search-highlight searches text and returns a highlighted copy, ready to display.
• Page geometry (intrinsic width and height per page) is reported by the same family, so viewers can lay out before rendering.
• POST /lmkit/v1/video-frames extracts frames from video files, and audio or video sound tracks transcribe through POST /lmkit/v1/audio-transcription (JSON with base64 or a file id, or multipart upload) using a local speech model from Models.

4Validation#

POST /lmkit/v1/document-validation checks a document against a conformance profile (PDF/A, ISO 19005) and reports the violations rather than a bare yes/no. Use it as the acceptance gate of an archival pipeline: convert, validate, and store the report with the artifact. The full archival workflow, conversion included, is PDF/A Conversion and Validation.

5Where the same pipeline appears again#

This pipeline is not exclusive to these endpoints: Search ingestion runs it on every indexed document, the playground's document chat runs it on attachments, and MCP document tools expose parts of it to connected agents. Learning its behavior once (formats, OCR, page model) pays off across the whole server.

6Stated plainly#

• One pipeline, many doors: any supported format becomes structured pages, OCR included, and every document capability builds on that.
• Upload once, reference by file id, chain endpoints; Markdown is the interchange when structure must survive.
• Validation turns archival conformance from a manual chore into an API call with an inspectable report; batch separation has its own chapter under Intelligent Document Processing.