File and Binary Handling

The Davix H2I n8n node uses a mixed input and output model:

• H2I uses structured text fields such as HTML and CSS
• Image, PDF, and Tools use binary file inputs
• H2I, Image, and PDF can optionally produce binary outputs by downloading returned URLs
• Tools is documented as JSON-oriented output rather than binary-download output

This page explains how the node reads input files, builds multipart requests, handles optional watermark file inputs, and attaches binary output to n8n items.

Binary input model overview #

The node implements binary input handling for these resources:

• Image
• PDF
• Tools

The H2I resource does not use input binary properties. Instead, it uses JSON fields such as html, css, dimensions, and rendering options.

The documented binary-input flow is:

• read a comma-separated list of binary property names from a resource-specific field
• trim and iterate those names
• read file buffers from the incoming n8n item
• attach those files to the outbound request as multipart input

Resource-specific binary input fields #

The node does not use one shared binaryPropertyName field for all resources. Instead, it defines separate input fields for each binary-driven resource.

Image input binary field #

For the Image resource, the input file field is:

• label: Input Binary Properties
• internal name: imageBinaryProps
• default: data

This field identifies which binary properties on the incoming n8n item should be uploaded for Image operations.

PDF input binary field #

For the PDF resource, the input file field is:

• label: Input Binary Properties
• internal name: pdfBinaryProps
• default: data

This field identifies which binary properties on the incoming n8n item should be uploaded for PDF operations.

Tools input binary field #

For the Tools resource, the input file field is:

• label: Input Binary Properties
• internal name: toolsBinaryProps
• default: data

This field identifies which binary properties on the incoming n8n item should be uploaded for Tools analysis operations.

How the node reads binary input #

The implementation reads files from incoming n8n binary data using this.helpers.getBinaryDataBuffer(itemIndex, propertyName). It also reads file metadata such as:

• fileName
• mimeType
• optional fileSize

This means the node expects binary data to already exist on the incoming item under the property names you provide. It reads those files from the item rather than generating or fetching them on its own.

Multiple file support #

The node supports multiple files for Image, PDF, and Tools because the input-binary field is treated as a comma-separated list of property names. The documented implementation splits the field value by comma, trims it, and iterates over the resulting names.

This means both of these patterns are supported:

• one binary property name
• multiple binary property names separated by commas

Validation for missing binary property lists #

The node validates the binary property list. When no binary property names are provided, it throws the validation error:

No binary property names provided.

This applies to binary-driven flows and is part of the node’s input-handling behavior.

Multipart request construction #

The node uses two request styles:

• H2I uses a JSON request body
• Image, PDF, and Tools use multipart formData

Binary upload behavior is therefore implemented only for Image, PDF, and Tools.

Image multipart construction #

For the Image resource:

• the node sends POST /v1/image
• the request payload is multipart formData
• uploaded files are attached under the multipart field name images

PDF multipart construction #

For the PDF resource:

• the node sends POST /v1/pdf
• the request payload is multipart formData
• uploaded files are attached under the multipart field name files

Tools multipart construction #

For the Tools resource:

• the node sends POST /v1/tools
• the request payload is multipart formData
• uploaded files are attached under the multipart field name images

These multipart field names are fixed in the documented implementation and are not exposed as editable node settings.

[Image placeholder — node editor showing Input Binary Properties for an Image or PDF operation]

File metadata preservation during upload #

When the node attaches files to multipart form data, it preserves metadata from the n8n binary object:

• filename comes from fileName, with generated fallbacks when needed
• content type comes from mimeType

This means the node carries filename and MIME type information into the multipart request when that metadata is available on the n8n item.

Optional watermark image file inputs #

The node supports optional single-file watermark image inputs in both Image and PDF workflows. The multipart field name for this optional upload is:

• watermarkImage

The related UI fields are:

• Image → watermark: watermarkImageBinaryProp
• Image → multitask: watermarkImageBinaryProp
• PDF → watermark: watermarkImageBinaryProp

These fields point the node to a single binary property that should be attached as the optional watermark image file input.

H2I input handling #

The H2I resource is the exception to the binary-input model. It uses a JSON request body and does not require input binary properties. Instead, its input model is based on structured fields such as:

• html
• css
• width and height
• render settings

This distinction matters because H2I workflows start from text and rendering options, while Image, PDF, and Tools workflows start from binary data already attached to the n8n item.

Binary output handling overview #

The node implements optional binary output handling for:

• H2I
• Image
• PDF

Output is always emitted as json, and for certain branches binary is added in addition to json. Whether binary is added depends on the resource-specific download settings.

The current node implementation does not document a binary-download output path for Tools. Tools is documented as JSON output.

H2I binary output behavior #

For H2I, if downloadBinary is enabled:

• the node gathers URLs from the response
• downloads the first URL
• converts the download into n8n binary data with prepareBinaryData
• stores it under the configured outputBinaryProperty

The matching UI fields are:

• downloadBinary
• outputBinaryProperty

Image binary output behavior #

For Image, if imageDownloadBinary is enabled:

• the node gathers returned URLs
• downloads the results
• stores them as binary data under imageOutputBinaryProperty
• when multiple files are downloaded, output property names may be suffixed with _0, _1, and so on

There is one important exception:

• the Image metadata operation forces binary-download behavior off in code

The matching UI fields are:

• imageDownloadBinary
• imageOutputBinaryProperty

PDF binary output behavior #

For PDF, if pdfDownloadBinary is enabled:

• the node gathers returned URLs
• downloads the output
• attaches it as binary data using the configured pdfOutputBinaryProperty

The matching UI fields are:

• pdfDownloadBinary
• pdfOutputBinaryProperty

How output URLs are gathered #

The implementation uses a helper to gather URLs from the response. The binary-download path relies on:

• response.url
• response result collections such as response.results[] and results[].url

If binary download is enabled but the response does not provide a downloadable URL, the node throws:

No URL returned to download.

Download helper behavior #

The implementation includes a dedicated downloadToBinary() helper used for binary-download output. When download is enabled, the node actively retrieves the file content and converts it into native n8n binary output rather than only passing through the URL.

[Image placeholder — node editor showing a download-binary toggle and output binary property field]

Upload-size validation #

The node includes upload-size validation for binary uploads. For exact numeric limits and related failure details, refer to the shared Errors and Limits page.

Sequential per-item processing #

Input items are processed sequentially in a for loop, and per-item request handling uses awaited operations. In practice, that means each item’s binary input and output is handled within its own request/response cycle.

What users should understand from this model #

The file and binary model can be summarized like this:

• H2I starts from structured text inputs and can optionally download output as binary
• Image starts from one or more image binary inputs and can optionally download results as binary
• PDF starts from one or more PDF binary inputs and can optionally download results as binary
• Tools starts from image binary inputs and returns JSON analysis results rather than documented binary downloads