Open WebUI Integration#

Overview#

Docling is available as a built-in document extraction plugin for Open WebUI, enabling Open WebUI's RAG pipeline to delegate document parsing (PDFs, Office files, etc.) to a docling-serve backend. 1

The integration is configured in Open WebUI's Admin Panel → Documents settings under Content Extraction Engine, pointing Open WebUI at a running docling-serve instance via DOCLING_SERVER_URL. Official usage documentation is maintained by the Open WebUI project at docs.openwebui.com/features/rag/document-extraction/docling.

The three Open WebUI configuration keys that control this integration are 2:

How Open WebUI Calls docling-serve#

Open WebUI passes conversion options to docling-serve via the DOCLING_PARAMS dict. These map directly onto docling-serve request body fields. A representative user configuration 3:

{
  "do_ocr": true,
  "ocr_preset": "rapidocr",
  "ocr_lang": ["en", "fr"],
  "ocr_custom_config": "{\"kind\": \"rapidocr\", \"backend\": \"torch\", \"lang\": [\"en\", \"fr\"]}",
  "do_table_structure": true,
  "table_cell_matching": true,
  "table_mode": "accurate",
  "pdf_backend": "dlparse_v4",
  "include_images": false,
  "generate_page_images": false,
  "do_picture_description": false
}

Note: This example uses ocr_preset (the current field) rather than the deprecated ocr_engine. See the OCR deprecation note below.

Open WebUI uses the async conversion path internally. This is important for two reasons:

1. OCR parameter handling: The /v1/convert/file (multipart) endpoint historically ignored ocr_engine and related OCR params, falling back to RapidOCR — while the async source endpoint applied them correctly. The Gradio UI in docling-serve uses /v1/convert/source/async internally, which is why it behaves differently from direct file API calls. 4

2. ocr_engine is deprecated — use ocr_preset: Replace "ocr_engine": "tesseract" with "ocr_preset": "tesseract" (or "rapidocr"). For Tesseract, ocr_lang uses + as separator (e.g., "eng+deu"), not a comma or array. 4

Version Compatibility & Known Breaking Changes#

v1.24.0 → v1.25.0 regression (Open WebUI breaks)#

Users upgrading the rocm72 image variant from v1.24.0 to v1.25.0 reported Open WebUI completely failing with: 3

Error calling Docling: Error calling Docling API: Not Found - Task result not found. Please wait for a completion status.

Root cause (confirmed): The rocm72 container image bakes English and Chinese RapidOCR models but omits the Latin character set (latin_PP-OCRv3_rec_mobile). In v1.25.0, a stricter model-validation path surfaces this as a task failure rather than silently continuing, causing GET /v1/result/{task_id} to return 404 to Open WebUI. This specifically affects users processing documents with non-English Latin-script languages (e.g., French, German).

Workaround: Add a post_start hook to download the missing Latin RapidOCR models before the service starts: 3

BASE=/opt/app-root/src/.cache/docling/models/RapidOcr
MS=https://www.modelscope.cn/models/RapidAI/RapidOCR/resolve/v3.8.0
# Download latin_PP-OCRv3_rec_mobile.pth and latin_dict.txt

Alternatively, pin to ghcr.io/docling-project/docling-serve-rocm72:v1.24.0 until the upstream image is fixed.

Tenant isolation (task result 404s)#

PR #628 hardened task retrieval endpoints (/v1/status/poll, /v1/result) to return 404 on tenant mismatch rather than 403, to prevent UUID probing. 5 If your deployment uses X-Tenant-Id routing, ensure Open WebUI sends a consistent tenant header, or leave multi-tenancy disabled.

docling-jobkit v2 (June 2026)#

The June 2026 release bumped docling-jobkit from >=1.23.1,<2.0.0 to >=2.0.0,<3.0.0 and removed the experimental KFP orchestrator. 6 The supported orchestration backends are now: local (default), rq, and ray. This should be transparent to Open WebUI, which only interacts with the HTTP layer.

Key References#