PDF to JSON / CSV / Excel

DocuShell now returns structured JSON for successful parse jobs rather than the older in-house `parse_v1` envelope. That means the stable contract lives in the root object and its `kids` tree.

This is a better fit for downstream systems that want the parser's original structure without DocuShell translating it into a second schema first.

Markdown, HTML, and plain text remain available as companion artifacts when you want text-oriented renditions of the same document.

JSON is the primary structured output. It is the document tree and is the best choice for APIs, indexing, and LLM ingestion pipelines.

Markdown and plain text are companion text artifacts. They are useful for human inspection, quick previews, search, and downstream systems that prefer lightly structured text.

HTML supports styled downstream rendering, while annotated PDF is a visual debug artifact for comparing detected structure to the source document.

If your PDF was created by scanning a physical document, it may contain images of text rather than selectable text. The Parse PDF API defaults to hybrid `auto` mode when the server OCR backend is configured.

DocuShell still checks extracted text density after parsing runs. If OCR is unavailable or the output stays near-empty, the API returns the stable `ocr_required` failure code.

For private browser-only OCR, use the OCR PDF workflow to create searchable text first, then parse the OCR result when you need JSON, Markdown, HTML, text, or annotated PDF artifacts.

The heavy lifting now happens in the parse worker, not in the browser. That lets DocuShell keep the public API contract stable and centralize error mapping, queueing, and artifact cleanup.

Fast page-count preflight uses qpdf instead of a second full parser pass, so request validation stays lightweight before the parse job starts.

Completed jobs expose timing metadata through the API, which makes load testing and rollout monitoring much easier than the old browser-only path.