Dynamic Report Rendering

Overview #

Davix H2I can render dynamic reports by converting HTML layouts into PDF or image outputs through the public HTML-rendering endpoint. In this workflow, the application prepares a report template using HTML and CSS, inserts dynamic data, and sends the template to Davix H2I. The rendering is executed by the H2I engine (PixLab), and the API returns a generated output URL.

This workflow is appropriate when applications need to generate structured output from data without operating their own HTML-rendering infrastructure. The broader Davix H2I docs explicitly support visual reports, automated documents, and automation workflows built on HTML rendering.

When to use this recipe #

Dynamic report rendering is suitable when an application needs to generate structured files automatically from application or analytics data. The platform’s HTML-rendering model supports layouts, templates, and dynamically generated markup that can be turned into visual or document outputs through an API call.

Example architecture #

Typical report-rendering flow:

Application / Analytics System
        │
        │ generate report HTML template
        │
        ▼
Davix H2I API
https://pixlab.davix.dev/v1/h2i
        │
        │ HTML rendered by
        │ H2I engine (PixLab)
        │
        ▼
Generated report URL
        │
        ▼
Used by the application workflow

This reflects the documented Davix H2I interaction model: the client sends an authenticated request, the backend rendering engine performs the work, and the result is returned as a generated file URL.

Step 1 — Create a report HTML template #

Davix H2I accepts HTML layouts, templates, and dynamically generated markup as input to the H2I rendering workflow. A report template can therefore be built as structured HTML and populated with dynamic values before sending it to the API.

Example report template:

<div style="font-family:Arial, sans-serif;padding:40px;">
  <h1>Monthly Performance Report</h1>
  <p><strong>Period:</strong> January 2026</p>
  <hr>
  <h2>Summary</h2>
  <p>Total Users: 4,532</p>
  <p>New Signups: 389</p>
  <p>Revenue: $12,480</p>
  <hr>
  <h2>Top Performing Pages</h2>
  <table style="width:100%;border-collapse:collapse;margin-top:20px;">
    <tr>
      <th style="text-align:left;border-bottom:1px solid #ccc;">Page</th>
      <th style="text-align:right;border-bottom:1px solid #ccc;">Views</th>
    </tr>
    <tr>
      <td>Homepage</td>
      <td style="text-align:right;">15,203</td>
    </tr>
    <tr>
      <td>Pricing</td>
      <td style="text-align:right;">8,994</td>
    </tr>
    <tr>
      <td>Blog</td>
      <td style="text-align:right;">6,782</td>
    </tr>
  </table>
</div>

Applications would replace the example values with real report data before rendering.

Step 2 — Send the rendering request #

Endpoint:

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

The /v1/h2i endpoint is the public HTML-rendering route. It accepts JSON or URL-encoded request bodies, supports both image and pdf actions, and requires API-key authentication. This recipe uses the pdf action.

Authentication is accepted through:

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

In non-production environments, body-based api_key and query-based ?key= are also accepted. In production, those locations are rejected.

Full example request #

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

This is the documented public example shape for the /v1/h2i PDF action and uses the supported public parameter set for that route.

Request parameters #

Parameter	Required	Description
action	yes	Determines the output type for /v1/h2i; use pdf here
html	yes	HTML content used for rendering
css	no	Additional CSS styling
width	no	Rendering viewport width
height	no	Rendering viewport height
pdfFormat	no	Page format for PDF output
pdfLandscape	no	Enables landscape orientation
pdfMargin	no	Defines page margins
preferCSSPageSize	no	Uses CSS page-size preference
scale	no	Render scaling factor
printMode	no	Print-oriented rendering mode
printBackground	no	Includes background styling

Documented PDF defaults:

• width: 1000
• height: 1500
• pdfFormat: A4
• pdfLandscape: false
• pdfMargin: 24
• preferCSSPageSize: true
• scale: 1
• printMode: false
• printBackground: true

Example success response #

A successful /v1/h2i request returns a generated output URL:

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

The documented success shape for /v1/h2i is { url, request_id? }. url is the required field, and request_id may also be included.

Output behavior #

H2I-generated outputs are served through the /h2i/* output path. Signed output URLs are protected by signed URL handling when signing is enabled. Clients should use the returned url directly rather than constructing output URLs manually.

Automation example #

A common report-generation pattern is:

Scheduled report job
        │
        ▼
Collect analytics data
        │
        ▼
Generate HTML report template
        │
        ▼
Send request to Davix H2I API
        │
        ▼
Receive generated report URL
        │
        ▼
Use the report in the application workflow

This aligns with the broader Davix H2I documentation describing automation workflows built around API-driven processing and generated outputs.

Limits and processing behavior #

The /v1/h2i route applies documented limits and controls, including:

• HTML length cap
• render width cap
• render height cap
• render pixel-area cap
• timeout handling
• concurrency control
• customer quota handling

The canonical limits documentation states:

• HTML over the cap returns html_too_large
• width and height are clamped to configured ceilings
• render pixel-area overflow is rejected
• semaphore wait exhaustion returns server_busy
• timeouts return timeout

The loaded docs are not fully aligned on the exact render-size error name:

• the error architecture uses render_size_exceeded
• the limits doc uses render_too_large for H2I pixel-area overflow

Because you want numeric limits centralized under Errors and Limits, this page should link there instead of repeating values here.

Relevant errors #

Relevant documented H2I errors for this workflow include:

• missing_field
• invalid_parameter
• html_too_large
• render_size_exceeded
• html_render_failed
• rate_limit_exceeded
• rate_limit_store_unavailable
• monthly_quota_exceeded
• server_busy
• timeout
• auth/idempotency errors such as invalid_api_key, key_expired, api_key_location_not_allowed, and invalid_idempotency_key

Because of the mismatch noted above, public wording about render-size failures should stay neutral unless your source docs are unified.

Summary #

This recipe demonstrates how to generate dynamic reports using Davix H2I’s HTML-rendering workflow.

The documented flow is:

• create an HTML report template
• send it to POST /v1/h2i
• render the output through the H2I engine (PixLab)
• receive a generated output URL in response