Authentication and Credentials

The Davix H2I n8n node uses a single custom credential type for all outbound API requests: Davix H2I (PixLab) API. In the repository, this credential type is implemented as DavixH2IApi, and the node references it through the internal credential name davixH2IApi. All supported resources in the node use this same credential model.

Credential type overview #

The repository defines exactly one custom credential type for this node.

  • Credential display name: Davix H2I (PixLab) API
  • Internal credential name: davixH2IApi

The node definition references this credential directly, so the same credential is used across all resources and operations rather than using separate credentials for H2I, Image, PDF, or Tools.

Credential fields #

The credential type exposes two fields:

  • Base URL
  • API Key

Base URL #

The Base URL field is defined as:

  • internal name: baseUrl
  • type: string
  • required: true
  • default value: https://pixlab.davix.dev
  • placeholder: https://pixlab.davix.dev

Its description in the credential definition is:

PixLab API base URL (no trailing slash). Example: https://pixlab.davix.dev

This Base URL is used by the shared request helper before resource endpoint paths such as /v1/h2i, /v1/image, /v1/pdf, and /v1/tools are appended.

API Key #

The API Key field is defined as:

  • internal name: apiKey
  • type: string
  • required: true
  • default value: empty string
  • password-style input: enabled through typeOptions: { password: true }

Its description in the credential definition is:

Your Davix PixLab API key.

Because the field is configured as a password-style field, it is intended to be entered and stored as a secret in the credential UI.

[Image placeholder — n8n credential screen showing the Base URL field and API Key field]

How the node uses credentials at runtime #

At runtime, the node reads the configured credential, extracts the Base URL and API key, validates them, and uses them to construct the outbound request. This logic is implemented in the shared request helper rather than separately in each resource branch.

This flow applies across all supported resources:

  • H2I
  • Image
  • PDF
  • Tools

In practice, the credential flow is:

  • read the configured credential
  • validate the Base URL
  • verify that the API key is present
  • build the final request URL
  • inject the authentication header
  • dispatch the HTTP request through n8n’s request mechanism

Authentication transmission #

The node sends authentication using a custom HTTP header:

  • x-api-key

The request helper merges existing request headers and adds x-api-key: apiKey. The implemented authentication method is therefore API key authentication through a custom header.

The loaded source files do not document an alternative authentication mode such as Bearer token authentication or OAuth for this node.

Base URL validation rules #

Before a request is sent, the shared helper enforces several Base URL validation checks. The Base URL:

  • must not be empty
  • must be a valid absolute URL
  • must use https:
  • must not include embedded URL credentials such as username or password in the URL itself

These are runtime checks enforced by the helper before request dispatch.

API key validation rules #

The node also validates that an API key is present before sending a request. If the API key is missing, the runtime helper throws an error instead of continuing with request dispatch.

This means an empty saved API key does not create a usable runtime authentication configuration. A request requires a valid API key before it can proceed.

How request URLs are built #

After validation, the helper combines the configured Base URL with the endpoint path used by the selected resource. The documented construction flow is:

  • normalize the Base URL
  • ensure the endpoint path has a leading slash
  • concatenate the Base URL and endpoint path

The implemented resource endpoint paths are:

  • /v1/h2i
  • /v1/image
  • /v1/pdf
  • /v1/tools

The credential therefore stores a single Base URL, not separate URLs for individual resources.

Credential security characteristics #

The repository’s security documentation confirms these credential-handling characteristics:

  • the credential type contains only baseUrl and apiKey
  • the API key field is configured as a password-style field
  • the node reads credentials at request time
  • the API key is inserted directly into request headers
  • no hashing, signing, or token-exchange flow is implemented for the API key
  • no explicit credential logging statements are documented in the runtime node code

The repository also does not define a separate credential authenticate block in the credential file. Authentication is applied manually in the request helper.

What is not implemented as an authentication method #

The loaded source files do not confirm any of the following for the n8n node:

  • Bearer token authentication
  • OAuth authentication
  • signed-request authentication
  • multiple auth modes selectable in the node UI

The correct public documentation position is that the node supports API key authentication through the x-api-key header, using the single credential type described on this page.

Relationship between credentials and node resources #

All supported resources use the same credential:

  • H2I
  • Image
  • PDF
  • Tools

The node does not define separate credentials for different resources or endpoint groups. One valid Davix H2I (PixLab) API credential is the authentication layer for the entire node.

Error conditions related to credentials #

The loaded error-handling documentation confirms runtime validation failures for credential and connection setup, including:

  • missing Base URL
  • invalid Base URL
  • non-HTTPS Base URL
  • embedded credentials in the Base URL
  • missing API key

These are configuration errors raised before a valid authenticated request can be completed. In practice, they should be treated as credential setup issues first.

Practical setup guidance #

A valid authentication setup for the node consists of:

  • selecting the Davix H2I (PixLab) API credential type
  • entering a valid HTTPS Base URL
  • entering a valid API key
  • selecting that saved credential in the node before execution

Once configured, the same credential is reused across all node resources and operations through the shared request helper.

[Image placeholder — n8n node panel showing the selected Davix H2I (PixLab) API credential]

Summary of the implemented authentication model #

The implemented authentication model for the n8n node is:

  • one credential type
  • two credential fields
  • HTTPS-only Base URL validation
  • required API key
  • API key sent in the x-api-key header
  • one shared credential used by all node resources and operations
Was it helpful ?
Table of contents
Login
Login
Login
Login
Scroll to Top