The Davix H2I n8n node is an n8n transform node that connects n8n workflows to the H2I engine (PixLab). In the node definition, it is configured as a transform node, uses node version 1, and requires a credential named davixH2IApi. Instead of exposing one fixed action, it uses a resource-and-operation interface that changes based on the selected resource.
The package name for this integration is n8n-nodes-davix-h2i. The node display name is Davix H2I, and its credential display name is Davix H2I (PixLab) API. The package is structured and published as an n8n community node.
What this node does #
The node exposes four top-level resources:
- H2I
- Image
- Tools
These resources drive which operations and fields are shown in the node UI.
H2I #
The H2I resource supports two operations:
- Render HTML to Image
- Render HTML to PDF
These operations are used for HTML and CSS rendering workflows.
Image #
The Image resource supports these operations:
- Format
- Resize
- Crop
- Transform
- Compress
- Enhance
- Padding
- Frame
- Background
- Watermark
- PDF Export
- Metadata
- Multitask
This makes the Image resource suitable for both single-purpose image transformations and combined multi-action processing.
PDF #
The PDF resource supports these operations:
- To Images
- Merge
- Split
- Compress
- Extract Images
- Watermark
- Rotate
- Metadata
- Reorder
- Delete Pages
- Extract Pages
- Flatten
- Encrypt
- Decrypt
The PDF resource is a separate workflow surface in the node, with its own operations and field set.
Tools #
The Tools resource supports two operation modes:
- Single Tool
- Multitask
Within those modes, the documented tool set includes metadata, colors, detect-format, orientation, hash, similarity, dimensions, palette, transparency, quality, and efficiency analysis.
How the node connects to the H2I engine (PixLab) #
The node connects through a shared helper named davixRequest. This helper reads the configured credentials, validates the base URL, injects the x-api-key header, and builds the final request URL from the configured base URL plus the selected endpoint path. The default base URL in the credential definition is https://pixlab.davix.dev.
The node uses four endpoint paths for execution:
/v1/h2i/v1/image/v1/pdf/v1/tools
Each resource sends a POST request to its corresponding path. The loaded source files do not document additional execution endpoints beyond these four.
How the node works in a workflow #
At runtime, the node processes incoming items in a loop. For each item, it reads the selected resource and operation, builds the request payload, sends the request through davixRequest, and emits one output item for that input item. This is a per-item execution model.
The request format depends on the selected resource:
- H2I uses a JSON body.
- Image uses multipart form data.
- PDF uses multipart form data.
- Tools uses multipart form data.
The node returns the backend response object in json for all resources. For H2I, Image, and PDF, it can also optionally download returned URLs and attach them as binary data in the output item. The Tools branch returns JSON only.
If continueOnFail() is enabled, item-level failures are emitted as structured error output and later items continue processing. If it is not enabled, execution stops on the thrown error.
Supported workflow types #
Based on the implemented resources and execution flow, the node supports several workflow categories.
HTML rendering workflows use the H2I resource to render HTML and CSS as either images or PDFs, with optional binary download when the response includes a downloadable URL.
Image-processing workflows use uploaded image binaries for format conversion, resizing, cropping, transforms, compression, enhancement, padding, framing, background processing, watermarking, metadata extraction, and multitask operations.
PDF workflows use uploaded PDF binaries for operations such as merge, split, compress, reorder, rotate, watermark, flatten, extract pages, extract images, encrypt, decrypt, and page-to-image conversion.
Image-analysis workflows use the Tools resource to run one tool or multiple tools in a single request against uploaded image binaries.
Binary-producing workflows can download response URLs and convert them into n8n binary output for downstream workflow steps. This applies to H2I, Image, and PDF operations.
Credentials and configuration #
The node uses one custom credential type: DavixH2IApi. That credential contains two required fields:
- Base URL
- API Key
The Base URL field defaults to https://pixlab.davix.dev, and the API Key field is configured as a password-style input in the credential UI.
Runtime validation enforces these checks before dispatch:
- Base URL must not be empty
- Base URL must be a valid absolute URL
- Base URL must use HTTPS
- Base URL must not include embedded credentials
- API key must not be empty
[Image placeholder — n8n credential screen showing Base URL and API Key fields]
Compatibility and package facts #
The package version documented in the repository is 1.0.0, while the node definition uses node version 1. The package metadata does not define a specific minimum or maximum n8n core version beyond peerDependencies.n8n-workflow: "*". The declared Node.js runtime requirement is >=20.
The repository documents two installation paths: installation through the n8n Community Nodes UI and installation through npm for self-hosted setups.
Security and transport characteristics #
Authentication is sent in the custom HTTP header x-api-key. The helper code injects this header after reading the stored credentials. The loaded source files do not document Bearer authentication, OAuth flows, or alternate auth modes for this node.
Credential injection is implemented manually in helper code rather than through a separate credential authenticate block. The base URL is configurable through the credential, and request construction combines that base URL with the selected endpoint path before dispatch.
Operational characteristics #
The node processes input items sequentially in a loop. The source files do not describe an internal parallel execution model.
The node includes request-side validation for common problems such as missing credentials, invalid base URL values, missing binary property names, missing selected tools or actions, invalid PDF reorder input, and missing download URLs when binary download is enabled. For numeric limits and full failure details, refer to the shared Errors and Limits page.
The source files do not document built-in retry logic in the node request path, and they do not document explicit runtime logging inside the node execution code.
Typical use cases #
This node is suited to workflows where n8n needs to:
- render HTML templates into images
- render HTML templates into PDFs
- transform uploaded images
- convert or modify PDFs
- analyze images for metadata, similarity, hashes, palette, dimensions, transparency, quality, or efficiency
- turn response URLs into binary data for downstream automation steps
[Image placeholder — n8n node editor showing the Resource field with H2I, Image, PDF, and Tools options]
