Output and Data Contracts

The Davix H2I n8n node returns output in a consistent n8n item structure: every successful execution path emits an output item with a json object, and some resource branches can also attach a binary object when binary download is enabled. The node builds output items manually and returns them as return [out].

This page documents the confirmed output model for the node:

• success output structure
• JSON pass-through behavior
• optional binary output behavior
• per-resource output notes
• error output structure
• continue-on-fail behavior
• what the node does and does not transform in responses

Output model overview #

The node processes input items in a loop and pushes one output item into out for each processed input item in normal success paths. At the end of execution, it returns return [out].

The documented output model is:

• output is always an n8n item containing json
• some branches also add binary
• the json payload is the backend response object returned by the request helper
• the node does not remap response fields into a new custom schema before returning them

This means the node acts primarily as a transport and workflow adapter: it adds n8n-compatible structure around the response, but it does not replace the backend response with a node-specific synthetic JSON schema.

Success output structure #

In a successful execution path, the node returns an item shaped like this:

{
  "json": {
    "<backend-defined-fields>": "returned unmodified by this node"
  }
}

This is the documented success contract: item.json is the backend response object returned from davixRequest.

When binary download is enabled for supported resources, the output item can additionally include a binary object:

{
  "json": {
    "<backend-defined-fields>": "returned unmodified by this node"
  },
  "binary": {
    "<configured-binary-property>": {
      "<n8n-binary-data>": "attached by the node after downloading a returned URL"
    }
  }
}

Binary is added only in branches where binary download is both implemented and enabled.

JSON output behavior #

Across all resources, the documented success JSON contract is the same:

• the backend response object is assigned to item.json
• the node does not rename fields
• the node does not inject custom success metadata
• the node does not normalize resource-specific responses into a shared synthetic schema

This behavior applies to:

• H2I
• Image
• PDF
• Tools

Users should therefore treat item.json as the backend-defined response from the selected endpoint, not as a node-invented response format.

Binary output behavior overview #

Binary output is optional and controlled by resource-specific download toggles. Binary output is implemented for:

• H2I
• Image
• PDF

The current documentation does not describe a binary-download output path for Tools. Tools is documented as JSON-only output.

Binary output is never the primary response. The primary response remains json; binary is an additional output path attached only when the matching download setting is enabled and the response includes a downloadable URL.

H2I output contract #

For the H2I resource, both supported operations, image and pdf, return the backend response object in item.json. The node does not wrap that response in a separate resource-specific schema.

When H2I binary download is enabled:

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

The matching H2I output fields are:

• downloadBinary
• outputBinaryProperty

Without binary download:

{
  "json": {
    "<backend H2I response>": "returned as-is"
  }
}

With binary download:

{
  "json": {
    "<backend H2I response>": "returned as-is"
  },
  "binary": {
    "<outputBinaryProperty>": {
      "<downloaded file>": "attached by the node"
    }
  }
}

Image output contract #

For the Image resource, each supported operation returns the backend response object as item.json. This applies to operations including:

• format
• resize
• crop
• transform
• compress
• enhance
• padding
• frame
• background
• watermark
• pdf
• metadata
• multitask

When imageDownloadBinary is enabled, the node can download returned URLs and attach them as binary data. The binary output field name is controlled by imageOutputBinaryProperty.

When multiple files are downloaded, the node can store them under suffixed binary property names such as _0, _1, and so on.

Image metadata exception #

There is one important exception:

• Image metadata forces binary download off in code.

So Image → metadata should be documented as JSON-only output in practice.

Image success without binary:

{
  "json": {
    "<backend Image response>": "returned as-is"
  }
}

Image success with binary:

{
  "json": {
    "<backend Image response>": "returned as-is"
  },
  "binary": {
    "<imageOutputBinaryProperty>": {
      "<downloaded file>": "attached by the node"
    }
  }
}

Image metadata success:

{
  "json": {
    "<backend metadata response>": "returned as-is"
  }
}

PDF output contract #

For the PDF resource, the output model follows the same overall pattern:

• the backend response is returned in item.json
• optional binary output is added only when pdfDownloadBinary is enabled
• binary output uses the configured pdfOutputBinaryProperty

This applies to PDF operations including:

• to-images
• merge
• split
• compress
• extract-images
• watermark
• rotate
• metadata
• reorder
• delete-pages
• extract
• flatten
• encrypt
• decrypt

PDF success without binary:

{
  "json": {
    "<backend PDF response>": "returned as-is"
  }
}

PDF success with binary:

{
  "json": {
    "<backend PDF response>": "returned as-is"
  },
  "binary": {
    "<pdfOutputBinaryProperty>": {
      "<downloaded file>": "attached by the node"
    }
  }
}

Tools output contract #

For the Tools resource, the output-contract files document JSON return behavior but do not document a binary-download output path. Tools is therefore documented as JSON-only output.

The Tools resource supports:

• single
• multitask

In both cases, the node returns the backend response object in item.json without resource-specific response remapping.

Tools success example:

{
  "json": {
    "<backend Tools response>": "returned as-is"
  }
}

Response pass-through behavior #

A central rule of this node’s output contract is that successful backend responses are returned unmodified in json. The output-contract documentation explicitly states that:

• the successful JSON payload is the backend response object returned by davixRequest
• the node does not remap response fields in execute()
• this.helpers.returnJsonArray is not used; output is built manually with out.push(...)

Downstream workflows should therefore treat json as a pass-through response from the selected API endpoint, not as a normalized cross-resource node schema.

How binary output is attached #

When binary download is enabled for H2I, Image, or PDF:

• the node collects response URL values
• downloads the relevant file content
• converts the download into n8n binary data
• attaches the binary data to the output item under the configured binary property name

This means the node does not merely expose downloadable URLs. With binary download enabled, it actively converts response URLs into native n8n binary output for downstream nodes.

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

Error output model #

The node wraps per-item execution in try/catch. If continueOnFail() is enabled, it does not stop the workflow. Instead, it emits an output item containing structured error information.

The documented error output contains:

• error
• optional description
• optional httpCode

In public terms, the error item shape is:

{
  "json": {
    "error": "<error message>",
    "description": "<optional details>",
    "httpCode": "<optional HTTP status>"
  }
}

Continue On Fail behavior #

The node explicitly supports continueOnFail(). The documented runtime behavior is:

• if continueOnFail() is true, failed items are emitted as error objects and execution continues for later items
• if continueOnFail() is false, the error is re-thrown and execution stops

This means the node’s output contract includes both success-path items and error-path items, depending on your n8n execution settings.

Backend error surface in output handling #

The request helper parses backend error envelopes and may include fields such as:

• code
• message
• hint
• requestId

That means error and description in continue-on-fail output may contain backend-derived details rather than only generic node-level messages.

Post-response download failure behavior #

If binary download is enabled but no downloadable URL is present in the response, the node throws:

No URL returned to download.

This is part of the effective output contract because binary attachment depends on the response containing a usable URL.

Item pairing behavior #

When continueOnFail() is enabled, the node emits error output paired to the item index. This preserves the per-item execution model in the output.

For multi-item executions, each output item still corresponds to a single processed input item, whether that item represents success or failure.

Per-resource summary #

The node’s output contracts can be summarized as follows:

H2I

• always returns backend response in json
• can optionally add binary
• binary uses outputBinaryProperty when enabled

Image

• always returns backend response in json
• can optionally add binary
• binary uses imageOutputBinaryProperty when enabled
• metadata is JSON-only in practice because binary download is forced off for that operation

PDF

• always returns backend response in json
• can optionally add binary
• binary uses pdfOutputBinaryProperty when enabled

Tools

• returns backend response in json
• no documented binary-download output path