Output Files

Many Davix H2I operations generate output files as the result of a successful request.

For file-producing operations, the H2I engine (PixLab) generates the output, stores it in the platform’s public output directories, and the API returns a structured response containing one or more output URLs. This is the standard output model for HTML rendering, many image-processing actions, and many PDF-processing actions.

What Output Files Represent #

Output files are the final processed assets created by a successful API operation.

Depending on the endpoint and action, output files can include:

  • rendered images
  • generated PDF documents
  • transformed image files
  • extracted or converted PDF-derived outputs

Not every endpoint returns downloadable files. Some operations return structured JSON instead of persisted output files.

Which Endpoints Produce Output Files #

The public API includes several file-producing routes:

  • /v1/h2i — writes outputs under the H2I output path and returns a signed url
  • /v1/image — many actions write outputs under the image output path and return one or more signed URLs
  • /v1/pdf — many actions write outputs under the PDF output path and return one or more signed URLs

The public API also includes /v1/tools, but its current implementation returns JSON analysis results and does not currently persist tool outputs into the public tools directory.

How Output Files Are Generated #

For file-producing requests, the processing flow is generally:

  1. the request is authenticated
  2. parameters and uploaded content are validated
  3. endpoint-specific limits and guards are applied
  4. the request is processed by the H2I engine (PixLab) and the route pipeline
  5. one or more output files are written into the corresponding public output directory
  6. the API returns a structured JSON response containing output URL information

Examples of file-producing operations confirmed in the loaded documentation include:

  • rendering HTML to an image
  • rendering HTML to a PDF
  • image transformation and export actions
  • PDF merge, split, extract, conversion, and related PDF actions

How Output Files Are Delivered #

Davix H2I does not normally embed raw output files inside the JSON success response.

Instead, file-producing endpoints return URLs pointing to generated files. Those files are then fetched through the public static output paths. Public output fetch paths include:

  • /h2i/*
  • /image/*
  • /pdf/*
  • /tools/* when relevant and enabled

Static output fetches can require signed URL query parameters when signed outputs are enabled.

Success Response Shapes #

Davix H2I does not use a single universal status + result.url response format for all file outputs.

The verified public success patterns are:

Single Output File #

Some actions return a single top-level url:

{
  "url": "https://pixlab.davix.dev/h2i/<generated-file>?exp=<...>&sig=<...>",
  "request_id": "<REQUEST_ID>"
}

This pattern is used by /v1/h2i and some file-producing /v1/pdf actions.

Multiple Output Files #

Some actions return a results array:

{
  "results": [
    {
      "url": "https://pixlab.davix.dev/image/<generated-file>?exp=<...>&sig=<...>",
      "format": "jpeg",
      "sizeBytes": 123456,
      "width": 1200,
      "height": 630,
      "quality": 90,
      "originalName": "input.png"
    }
  ],
  "request_id": "<REQUEST_ID>"
}

This pattern is used by many /v1/image actions and some /v1/pdf actions.

Response Fields #

url #

A direct URL to a generated output file.

This field is returned when the action produces a single output file. The URL points to a file served from the appropriate public output path, such as /h2i/*, /image/*, or /pdf/*.

results #

An array of output objects.

This is used when an action generates multiple result files or returns one result object per processed input.

request_id #

A request identifier attached to the response.

This can be used for request tracking, debugging, and support. The server attaches request IDs at the global middleware layer and exposes them through response handling.

Accessing Output Files #

Once your application receives an output URL, it can use that URL to retrieve the generated file.

Common usage patterns include:

  • downloading the file
  • displaying the file in an application
  • copying the file into your own storage system
  • passing the file URL into another system or workflow

Because output URLs may be signed and because files are served from platform-managed public output paths, applications that need long-term storage should persist important files in their own systems after retrieval. The platform also runs cleanup jobs for public output directories.

Output File Types #

The file type depends on the endpoint and action.

Confirmed public examples include:

  • image outputs under the H2I route, such as PNG or JPEG render results
  • PDF outputs from H2I render mode
  • image-processing outputs written under the image output path
  • PDF-processing outputs written under the PDF output path

The exact output extension and structure depend on the selected action.

Output Availability and Static Access #

Generated output files are served through public static paths managed by the platform.

When signed output protection is enabled, static access requires signature query parameters such as exp and sig, which are produced when the URL is built. The static serving layer also applies response headers for cache and content-type hardening.

The platform also runs cleanup jobs that remove old files from public output directories. Public documentation should therefore encourage customers to retrieve and store important outputs in their own systems instead of treating platform-hosted output URLs as permanent archival storage.

Example Workflow #

A typical file-producing workflow looks like this:

  1. your application sends a valid authenticated request
  2. the platform validates the request and processes the operation
  3. the H2I engine (PixLab) generates the output file
  4. the API returns a response with url or results[]
  5. your application fetches the generated file and uses or stores it

This flow applies to file-producing actions on /v1/h2i, /v1/image, and /v1/pdf.

Using Output Files in Automated Systems #

In automated workflows, output URLs are commonly used in downstream steps such as:

  • attaching a generated PDF to an email
  • publishing a generated image
  • uploading a result into cloud storage
  • passing a processed file to another internal workflow

The public API’s output URL model is designed to make those downstream integrations straightforward.

Important Scope Note #

Not every successful Davix H2I operation returns a generated file URL.

In particular:

  • /v1/image with metadata-style behavior can return JSON data instead of output files
  • /v1/tools currently returns JSON analysis payloads and does not currently persist public downloadable tool outputs

This distinction is important when integrating the API. Applications should parse responses according to the endpoint and action they are calling.

Summary #

Output files are the final result of many Davix H2I processing operations.

For file-producing routes, the H2I engine (PixLab) generates the output, stores it in the platform’s public output paths, and the API returns one or more output URLs. This model is used by /v1/h2i, many /v1/image actions, and many /v1/pdf actions. Some operations, especially analysis-style endpoints such as /v1/tools, return JSON results instead of downloadable output files. Applications should retrieve important outputs promptly and store them in their own systems when long-term retention is required.

Was it helpful ?
Table of contents
Login
Login
Login
Login
Scroll to Top