For the complete documentation index, see llms.txt. This page is also available as Markdown.

Using Docling in n8n

Introduction

Docling is an advanced document parsing engine designed to convert complex, multi-format documents (such as PDFs, DOCX, and PPTX) into clean, LLM-ready Markdown or JSON structures. Integrating Docling into your n8n workflows within the GLBNXT ecosystem allows you to build highly accurate Retrieval-Augmented Generation (RAG) pipelines and document processing agents.


Why use Docling?

While standard document parsers perform basic text extraction, Docling is specifically designed for advanced, layout-aware document processing. It excels especially in the following categories:

  • Layout & Structure Preservation: Docling is able to accurately identify headers, sub-headers, reading order, multi-column layouts, and list structures.

  • Complex Tables: Standard parsers often scramble table data into disjointed lines. Docling preserves the underlying tabular grid, converting it cleanly into Markdown tables or structured JSON without losing column relationships.

  • Format Acceptability: It seamlessly handles a wide array of file formats (PDF, DOCX, XLSX, PPTX, HTML, images) through a single extraction engine.

Integrating Docling into n8n is ideal when your RAG workflows rely heavily on complex PDFs, reports, research papers, and technical documents where maintaining original document layout, structure, and tabular integrity is critical for retrieval accuracy.

Note: Converting complex or image-heavy PDFs takes noticeable processing time per page, making real-time batch ingestion slower unless optimized with GPU acceleration. For simple, single-column text files or raw .txt/.md files, Docling’s overhead is unnecessary and standard native parsers will be faster.


Prerequisites

Before configuring Docling within your n8n workflows, ensure you have the following:

  • n8n Environment: An active instance of n8n running within your secure GLBNXT workspace.

  • Docling Credentials: Use the url provided in Installation to setup your Docling Account.


Installation

Step 1: Add an HTTP Request Node

  1. Create a new workflow or open an existing one

  2. Open the nodes panel by selecting + or pressing N

  3. Add an HTTP Request Node to your workflow

Step 2: Configure Node

Option 1: Convert a File Passed from a Previous n8n Node (Multipart Form)

Use this method when you have a binary file (e.g., from an Email Read, Read/Write Files from Disk, or Google Drive node) in your n8n workflow.

  1. Configure the Parameters:

    • Method: POST

    • URL: Find in GLBNXT Applications > Services > Docling (make sure to add /v1/convert/file after the Endpoint)

    • Authentication: Select None

    • Send Body: Toggle ON

    • Body Content Type: Form-Data

  2. Under Specify Body, add your form fields:

    • Field 1 (The File):

      • Parameter Type: Form Data Item

      • Form Data Type: Binary File

      • Name: files

      • Input Data Field Name: File (or the name of your binary variable)

    • Field 2 (Output Format - Optional):

      • Parameter Type: Form Data Item

      • Form Data Type: Text

      • Name: to_formats

      • Value: md (or json, text, html)

Option 2: Convert a Public Document URL (JSON Body)

Use this method if you want Docling to download and parse a document directly from a URL.

  1. Configure the Parameters:

    • Method: POST

    • URL: Find in GLBNXT Applications > Services > Docling (make sure to add /v1/convert/source after the Endpoint)

    • Send Body: Toggle ON

    • Body Content Type: JSON

    • Specify Body: Using JSON

    • JSON Body:


Configuration

This section covers all configuration options available in Docling. Use these parameters to customize extraction pipelines, adjust OCR models, tune table structure identification, and tweak Vision-Language Models (VLM).

1. Document Format & Export Configurations

from_formats

  • Type: string

  • Default: Select (All/Auto)

  • Description: Filters or explicitly defines the allowed incoming file formats for processing.

  • Useful Scenario: If you want to ensure your pipeline ignores accidental spreadsheet uploads and strictly handles legal briefs, you can restrict this option to source formats like PDF or Word.

to_formats

  • Type: string

  • Default: Empty

  • Description: Specifies the desired target output format(s) for the converted document (e.g., Markdown, JSON, HTML).

  • Useful Scenario: Set this to Markdown if you are feeding the resulting text chunks straight into an LLM context window.

image_export_mode

  • Type: string

  • Default: Embedded

  • Description: Controls how extracted document images are packaged within the final export file.

  • Useful Scenario: Set to Embedded if you require an autonomous single-file asset containing base64 images. Use alternative referenced paths if you prefer keeping file sizes lean.

image_scale

  • Type: number

  • Default: 2

  • Description: Adjusts the scaling multiplier or resolution modifier applied to images extracted from the document body.

  • Useful Scenario: Increase the scaling value if you notice that embedded charts or handwritten notes require higher clarity for downstream human review or secondary inspection.

include_images

  • Type: boolean

  • Default: true (Enabled)

  • Description: Determines whether visual images, figures, and graphical assets should be preserved and extracted alongside the text.

  • Useful Scenario: Turn this toggle off to speed up processing times and save storage if you only care about textual data extraction.

2. OCR (Optical Character Recognition) Controls

do_ocr

  • Type: boolean

  • Default: true (Enabled)

  • Description: Activates or deactivates OCR parsing on bitmap, scanned, or non-selectable visual documents.

  • Useful Scenario: Turn this off if you exclusively process raw digital-native text documents (like direct HTML or system-generated text files) to drastically decrease overall execution latency.

force_ocr

  • Type: boolean

  • Default: false (Disabled)

  • Description: Replaces a PDF file's native underlying text layer entirely with freshly synthesized characters computed directly via the active OCR engine.

  • Useful Scenario: Indispensable for handling legacy documents possessing corrupted or misaligned embedded text tracks where copy-pasted words manifest as gibberish.

ocr_engine

  • Type: string

  • Default: Auto

  • Description: Selects the structural toolkit ecosystem deployed for running standard OCR extraction models.

  • Useful Scenario: Switch from Auto to a specific engine framework if your hosting environment implements a highly optimized local engine binary.

ocr_lang

  • Type: string (Comma-separated text input)

  • Default: Empty (en, de, fr placeholder)

  • Description: Feeds targeted explicit language code requirements down to the underlying active engine library instances.

  • Useful Scenario: Explicitly supply regional language tags when parsing complex multi-lingual trade contracts containing specific localized character accents.

3. Core Engine Pipelines & Table Management

pdf_backend

  • Type: string

  • Default: Diparse V4 (Default)

  • Description: Adjusts the specific backend library framework engine targeted for decoding layout coordinates and structural features inside PDF binaries.

  • Useful Scenario: Swap backends if a highly specialized PDF formatting layout fails to map correctly under the default parser.

do_table_structure

  • Type: boolean

  • Default: true (Enabled)

  • Description: Toggles whether advanced spatial structure extraction features should map grid blocks across document tables.

  • Useful Scenario: Turn this off when digitizing narrative-heavy text novels or basic text logs to skip intensive spatial positioning passes.

table_mode

  • Type: string

  • Default: Accurate (Default)

  • Description: Adjusts the structural layout identification weight models toward high-speed or deep-accuracy parsing algorithms.

  • Useful Scenario: Select a faster mode for rapid real-time screen indexing pipelines, or leave it on Accurate when transforming detailed multi-column financial reports.

pipeline

  • Type: string

  • Default: Standard (Default)

  • Description: Instructs the system which core processing assembly pipeline template path executes your ingestion.

  • Useful Scenario: Switch to specialized alternative pipelines if your specific document workflow requires custom model routing on intensive graphic structures.

4. System Execution Constraints

document_timeout

  • Type: number (Numeric input field)

  • Default: 300 (seconds)

  • Description: Sets the maximum processing time allowed for a single document workflow before forcing a thread cancellation.

  • Useful Scenario: Lower this value in user-facing synchronous web applications to prevent corrupted or excessively massive files from hanging server worker threads.

abort_on_error

  • Type: boolean (Toggle switch)

  • Default: false (Disabled)

  • Description: Dictates whether the pipeline should immediately crash upon encountering an exception or log it and keep processing remaining pages.

  • Useful Scenario: Turn this toggle on during strict automated validation testing, or leave it disabled in bulk-production setups so a single corrupted layout segment doesn't ruin a large batch import.

5. Document Bounds Management

page_range_start

  • Type: number

  • Default: 0 (Processes from the true start of the document)

  • Description: Sets the initial page boundary index where processing, layout rendering, and text conversion begin.

  • Useful Scenario: Set to a specific page number if you wish to skip introductory title pages, table of contents, or legal disclaimers.

page_range_end

  • Type: number

  • Default: 0 (Processes until the end of the document)

  • Description: Caps the maximum page bounds. A value of 0 processes the entire asset through its final page.

  • Useful Scenario: When parsing 500-page corporate financial filings but your analytics application only needs the introductory summary, set an ending bounds limit to save resources.


Troubleshooting

Issue: Timeout Errors on Large PDF Documents

  • Cause: Complex or multi-hundred-page PDFs can require significant processing time for layout and OCR analysis.

  • Solution: Increase the Timeout parameter within the n8n HTTP Request node settings (under Advanced Settings) to 300000 ms (5 minutes) or split massive document streams into smaller chunks prior to parsing.

Issue: Binary File Property Missing

  • Cause: The HTTP Request node is looking for a binary property that doesn't match the output name of the incoming source file.

  • Solution: Verify the input scheme. Check the execution data from the preceding node and match the property name exactly (e.g., attachment_0 vs data).

Issue: Network Isolation / Connection Refused

  • Cause: GLBNXT’s default strict security compliance policy blocks unauthorized traffic between containers.

  • Solution: Ensure that your n8n network policies explicitly allow outbound requests to the internal microservice endpoint hosting Docling.


Need help? Contact the GLBNXT support team or ask a GLBNXT agent to walk you through the setup.

Last updated

Was this helpful?