Building Automated Reports

Overview #

Automated report generation is a natural workflow for Davix H2I because the platform’s core HTML-rendering capability allows applications to convert dynamic HTML into image or PDF outputs through API requests. This is one of the main ways Davix H2I is used in automation and document-generation workflows. Requests sent to Davix H2I are executed by the H2I engine (PixLab), which performs the backend rendering and returns a generated output URL.

This workflow is useful when an application already knows how to produce structured layouts in HTML and needs to turn those layouts into report files without operating its own rendering stack. Davix H2I provides that rendering layer through a structured API interface.

When to use automated reports #

Automated reporting workflows are useful when your system needs to generate structured files from application data without manual work. The loaded documentation supports use cases such as:

  • generating visual reports
  • producing automated documents
  • rendering HTML-based designs into PDF documents
  • integrating report generation into automation workflows

In these workflows, the application builds an HTML document and sends it to Davix H2I for rendering.

Architecture of an automated report workflow #

A typical automated report workflow follows these steps:

  1. Your application collects data from its own source systems.
  2. Your application injects that data into an HTML template.
  3. Your application sends the rendered HTML to Davix H2I.
  4. The H2I engine (PixLab) processes the request and generates the output file.
  5. The API returns a signed URL to the generated report file.
  6. Your application uses that returned file URL in its own workflow, such as storing it, displaying it, or passing it to another system.

Because the rendering infrastructure runs on the Davix H2I backend, the application does not need to operate its own HTML rendering service. This matches the product’s role as a backend processing layer inside larger automation systems.

Using HTML templates for reports #

The recommended pattern for automated reports is to build reusable HTML templates and populate them with dynamic data before sending them to the API. The platform documentation explicitly supports sending HTML layouts, templates, or dynamically generated markup for rendering into image or PDF output.

Example template structure:

<html>
<head>
  <style>
    body {
      font-family: Arial, sans-serif;
      margin: 40px;
    }
    h1 {
      margin-bottom: 20px;
    }
    table {
      width: 100%;
      border-collapse: collapse;
    }
    td, th {
      border: 1px solid #ddd;
      padding: 8px;
    }
  </style>
</head>
<body>
  <h1>Monthly Sales Report</h1>
  <table>
    <thead>
      <tr>
        <th>Product</th>
        <th>Units Sold</th>
        <th>Revenue</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>Product A</td>
        <td>120</td>
        <td>$4,200</td>
      </tr>
      <tr>
        <td>Product B</td>
        <td>80</td>
        <td>$2,900</td>
      </tr>
    </tbody>
  </table>
</body>
</html>

Your application would generate this HTML dynamically and replace the example values with real report data before sending it to the API.

Rendering the report as a PDF #

Davix H2I supports HTML-to-PDF rendering through POST /v1/h2i with action=pdf. The same endpoint also supports image output through action=image, but this workflow focuses on PDF report generation.

Endpoint #

POST https://pixlab.davix.dev/v1/h2i

This endpoint is part of the public external API surface for HTML rendering. It accepts JSON or URL-encoded bodies.

Authentication #

/v1/h2i requires API key authentication. External /v1/* routes accept:

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

In production, body/query API key transport is rejected, so public integrations should authenticate through headers.

Example API request #

curl -sS -X POST "https://pixlab.davix.dev/v1/h2i" \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Idempotency-Key: idem-ext-001" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "pdf",
    "html": "<h1>Monthly Sales Report</h1>",
    "css": "body{font-family:sans-serif}",
    "width": 1000,
    "height": 1500,
    "pdfFormat": "LETTER",
    "pdfLandscape": false,
    "pdfMargin": 24,
    "preferCSSPageSize": true,
    "scale": 1,
    "printMode": false,
    "printBackground": true
  }'

This uses the documented public parameter set for the /v1/h2i PDF action.

Required fields #

FieldDescription
actionMust be pdf for PDF output
htmlHTML document to render

Optional fields #

FieldDescription
cssCSS styles applied during rendering
widthRender width
heightRender height
pdfFormatPage format
pdfLandscapeLandscape orientation
pdfMarginPage margin
preferCSSPageSizeUse CSS page-size preference
scalePage scaling factor
printModePrint-oriented render mode
printBackgroundEnables CSS background rendering

These are the documented PDF-related parameters supported by /v1/h2i in PDF mode. Defaults are width=1000, height=1500, pdfFormat=A4, pdfLandscape=false, pdfMargin=24, preferCSSPageSize=true, scale=1, printMode=false, and printBackground=true.

Example success response #

A successful request returns a JSON response containing the generated output URL.

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

The success shape for this route is { url, request_id? }, so url is the required field and request_id may also be included. H2I outputs are served through the /h2i/* output path and returned as signed URLs.

Delivering the generated report #

Once the API returns the output URL, your application can use that file in its own workflow. For example, it may:

  • provide a download link
  • store the returned URL
  • pass the file URL to another system
  • use the output in a larger automation process

Davix H2I handles the rendering and file generation. Downstream delivery is handled by the calling application or connected workflow. This is consistent with the platform’s role as the processing component within larger automation pipelines.

Handling limits in report generation #

The /v1/h2i route applies platform guards designed to protect the rendering system. The loaded docs show enforcement for:

  • HTML input size
  • render width
  • render height
  • render pixel area
  • timeout handling
  • concurrency control
  • quota handling for customer keys

The canonical H2I limits documentation also shows an important detail:

  • width and height are clamped to configured limits
  • pixel-area overflow is rejected

Because you want customer-facing numeric limits centralized in one place, this page should link to your Errors and Limits section instead of repeating values here.

One source mismatch also matters here:

  • the cURL examples doc names the pixel-area failure render_size_exceeded
  • the limits doc names it render_too_large

Until your source docs are unified, this guide should use neutral wording such as render-size limit error instead of asserting a single final code.

Error handling #

If a report request fails, the API returns the standard JSON error structure used across the external API.

Example error:

{
  "status": "error",
  "code": "html_render_failed",
  "message": "Rendering process failed",
  "error": {
    "code": "html_render_failed",
    "message": "Rendering process failed"
  },
  "request_id": "<REQUEST_ID>"
}

This matches the documented external error envelope structure. Relevant errors for this workflow include invalid_parameter, missing_field, html_too_large, rate_limit_exceeded, rate_limit_store_unavailable, monthly_quota_exceeded, server_busy, timeout, and html_render_failed, along with auth/idempotency errors such as invalid_api_key, key_expired, api_key_location_not_allowed, and invalid_idempotency_key.

Applications generating automated reports should log the request_id when present so failures can be traced more easily.

Best practices for automated reports #

  • Build reusable HTML templates so report structure stays consistent.
  • Keep data generation separate from template generation.
  • Use HTML and CSS to control layout, tables, typography, and spacing.
  • Validate API responses and log request identifiers for troubleshooting.

These practices are consistent with the platform’s HTML-rendering model and with its role inside automated generation workflows.

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