Platform Architecture

Davix H2I is built as a layered platform that provides access to backend media and document processing capabilities through a structured service interface. The architecture separates the user-facing product and API layer from the underlying execution layer, allowing applications, websites, and workflows to interact with advanced backend processing capabilities through consistent HTTP-based integration patterns.

This separation allows Davix H2I to remain accessible and integration-friendly while the H2I engine (PixLab) performs the computational work behind the scenes.

Ecosystem Structure #

Davix H2I exists within the broader Davix Labs ecosystem and follows a layered structure in which each layer has a different responsibility.

Davix Labs #

Davix Labs is the parent brand and development organization behind the ecosystem. It builds and maintains the technologies, services, plugins, APIs, and related systems that support products such as Davix H2I.

Davix H2I #

Davix H2I is the product and access layer. It provides the public-facing service interface through which users access backend processing capabilities using API keys, documentation, integrations, and supported tools. It is the product layer customers interact with when integrating the service into applications, websites, or automation workflows.

H2I engine (PixLab) #

The H2I engine (PixLab) is the backend execution layer. It performs the computational work requested through Davix H2I, including HTML rendering, image processing, PDF processing, media conversion and transformation, and analysis-related tasks. It operates as an internal technology layer and is not intended to function as a separate user-facing product.

API Layer and Public Route Structure #

Davix H2I exposes its core public processing API through the main /v1/* route groups:

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

These routes are mounted as the external/public API surface and are handled by dedicated route modules for each capability area.

In addition to the processing API, the platform also exposes:

  • /health as the public healthcheck route
  • /h2i/*, /image/*, /pdf/*, and /tools/* as public static output fetch paths.

API Layer Responsibilities #

Within the architecture, Davix H2I is responsible for the service-layer concerns that sit between the user and the backend execution engine. These include:

  • exposing the public API routes
  • authenticating requests with API keys
  • validating incoming requests
  • applying endpoint access rules and usage controls
  • routing accepted work to the H2I engine (PixLab)
  • returning the final result through the public interface.

Core API communication with the platform occurs through this layer, while the underlying processing work is delegated to the execution engine.

Communication Model #

Davix H2I uses standard HTTP-based communication.

At the public API level:

  • /v1/h2i accepts JSON or URL-encoded request bodies for HTML rendering
  • /v1/image accepts multipart/form-data
  • /v1/pdf accepts multipart/form-data
  • /v1/tools accepts multipart/form-data.

Public /v1/* authentication accepts:

  • Authorization: Bearer <key>
  • X-Api-Key: <key>

Depending on the endpoint, a request may include action parameters, HTML content, uploaded files, and route-specific options.

Request Flow Architecture #

The request lifecycle follows a structured pipeline through the platform.

1. Request Metadata #

A request ID is attached very early in the lifecycle and is propagated through the response flow. The platform also mirrors it as the Request-Id response header.

2. Authentication #

For public /v1/* requests, the platform validates the API key before the request proceeds to the endpoint handler. Invalid, missing, or expired keys are rejected before processing.

3. Validation and Route Handling #

After authentication, Davix H2I applies request validation, endpoint gating, and route-specific handling. Depending on the endpoint, this may include request-shape validation, upload validation, supported action checks, and usage-control gates. Detailed numeric limits belong in the Errors and Limits section rather than on this page.

4. Processing Execution #

Once the request is accepted, the relevant route passes the work into the H2I engine (PixLab), which executes the underlying operation. This may involve rendering HTML, transforming images, processing PDF documents, or executing analysis-related tasks.

5. Result Delivery #

After execution completes, the result is returned through Davix H2I. For file-producing operations, the response returns signed output URLs. For analysis-oriented operations, the response may instead return structured JSON data.

Output Delivery Architecture #

The platform prepares public static output paths for generated files under:

  • /h2i/*
  • /image/*
  • /pdf/*
  • /tools/*

When signed output protection is enabled, output access is guarded by signature and expiry validation. This means output URLs may be time-limited depending on platform configuration.

For public customer-facing documentation, it is important to understand that not every operation returns a hosted file. File-producing routes return output URLs, while tools-related analysis flows return structured JSON payloads.

Designed for Scalability and Separation of Responsibility #

The architecture separates responsibilities clearly:

  • the Davix H2I layer manages service access, validation, and integration
  • the H2I engine (PixLab) performs the computational processing work.

This separation allows the platform to centralize backend processing while keeping the external integration model simple and consistent for users.

Integration Model #

Because Davix H2I operates through HTTP-based APIs and supported integrations, it can be integrated into backend services, automation workflows, websites, CMS-based systems, and content-generation platforms. The documentation also supports integrations such as WordPress and n8n, as well as certain web-based access paths.

This makes Davix H2I a modular processing component that can sit inside larger software systems and automation environments.

Summary #

Davix H2I is built on a layered architecture that separates user-facing service access from backend execution. Davix Labs provides the parent ecosystem and development foundation, Davix H2I provides the public product and API layer, and the H2I engine (PixLab) performs the underlying computational work.

Public requests flow through authenticated and validated /v1/* endpoints, are executed by the backend engine, and then return either signed output URLs or structured JSON results depending on the operation. This architecture allows applications and workflows to access advanced backend processing capabilities without building or maintaining the infrastructure themselves.

Was it helpful ?
Scroll to Top