Davix H2I is an API-based backend processing platform that allows applications, websites, and automation workflows to perform media and document operations through a centralized processing service. Instead of executing these operations locally, connected systems send requests to Davix H2I, which processes the request through its backend infrastructure and returns the result through the platform interface.
This model allows developers, businesses, and automation systems to access advanced processing capabilities without building and maintaining their own rendering engines, transformation pipelines, or document-processing infrastructure.
Processing Architecture #
Davix H2I operates as part of the broader Davix Labs ecosystem and follows a layered architecture that separates service access from backend execution.
Davix H2I #
Davix H2I is the product and service access layer. It provides the public API surface, documentation, API-key-based access, and supported integration paths through which users interact with the platform. It is the primary interface through which customers access the platform’s capabilities.
H2I engine (PixLab) #
The H2I engine (PixLab) is the backend execution layer. It performs the computational operations requested through Davix H2I, including HTML rendering, image processing, PDF operations, media conversion and transformation, and analysis-related tasks.
Davix H2I manages access, request handling, and integration, while the H2I engine (PixLab) performs the actual processing work.
API Interaction #
Davix H2I exposes its core public processing API through HTTP endpoints. The main processing endpoint groups are:
/v1/h2ifor HTML rendering/v1/imagefor image processing/v1/pdffor PDF operations/v1/toolsfor tools-related and analysis-related processing.
Requests to these public endpoints are authenticated through API-key-based access. The public /v1/* routes accept either:
Authorization: Bearer <key>X-Api-Key: <key>
Depending on the endpoint, a request can include parameters, content, and uploaded files needed for the requested operation. For example, /v1/h2i accepts JSON-based render instructions, while /v1/image, /v1/pdf, and /v1/tools can involve uploaded files and route-specific parameters.
Request Lifecycle #
Each request follows a structured lifecycle inside the platform.
1. Authentication #
The request is authenticated using the provided API key. Invalid or missing keys are rejected before the request reaches the processing stage.
2. Validation and Route Handling #
After authentication, Davix H2I applies the relevant request validation and route-level checks. Depending on the endpoint, this can include validating request structure, accepted input types, supported actions, and platform limits. Detailed numeric limits are documented separately in the Errors and Limits section.
3. Processing Execution #
Once the request is accepted, the operation is routed to the H2I engine (PixLab), which performs the requested computational task. Depending on the endpoint, this may involve rendering HTML, transforming images, processing PDF documents, converting files, or executing analysis-related operations.
4. Output Generation #
For file-producing operations, the platform generates the output and writes it to the corresponding public output path. For certain operations, the result may instead be returned as structured JSON data rather than as a generated file.
5. Response Delivery #
After processing completes, Davix H2I returns the result to the client. Depending on the operation, the response may include generated output URL values, signed file URLs, or structured JSON data. The request lifecycle also carries a request_id, which is attached to standard response and error flows for traceability.
Output Delivery #
Generated file outputs are served through public output paths mounted by the platform:
/h2i/*/image/*/pdf/*/tools/*
When signed output protection is enabled, these output URLs require signature and expiry validation. This means output access may be time-limited depending on platform configuration.
Example Workflow #
A typical Davix H2I workflow looks like this:
- A system prepares the content or files needed for an operation.
- The system sends an authenticated request to the appropriate
/v1/*endpoint. - Davix H2I validates and routes the request.
- The H2I engine (PixLab) executes the requested processing task.
- Davix H2I returns the result as a generated output URL or structured response data, depending on the operation.
Integration Flexibility #
Davix H2I can be integrated into many kinds of environments. The platform supports direct API use in custom applications and backend services, integration into websites and CMS-based environments, workflow automation through n8n, and plugin-based access through WordPress. Some capabilities may also be available through web-based interfaces.
Because the platform operates through HTTP-based interfaces and integration layers, it can be used from a wide range of systems that need backend processing capabilities.
Designed for Automation #
Davix H2I is particularly well suited for automated workflows in which systems need to generate or transform content dynamically. A workflow can prepare content, send it to Davix H2I, receive the generated result, and then continue processing automatically inside the calling application or automation system.
This makes Davix H2I an effective backend component for systems that depend on automated rendering, media transformation, document generation, and file-processing workflows.
Summary #
Davix H2I works by exposing a structured API through which applications, websites, and automation workflows can request backend processing operations. Requests are authenticated, validated, routed, and executed by the H2I engine (PixLab), which performs the underlying computational work on behalf of the calling system.
For file-producing operations, the platform returns generated output URLs through public output paths. For certain other operations, it returns structured JSON data. This architecture gives users access to advanced backend media and document processing capabilities without requiring them to build and maintain the execution infrastructure themselves.
