Automated Invoice PDF Generation

Overview #

Davix H2I can generate invoice PDFs automatically by rendering HTML templates through the public HTML-rendering endpoint. In this workflow, the application prepares an invoice layout as HTML, sends it to Davix H2I with action=pdf, and receives a generated PDF URL in response. The rendering process is executed by the H2I engine (PixLab) behind the Davix H2I product layer.

This recipe is appropriate when an application needs to create structured document output from dynamic data without operating its own HTML-to-PDF rendering infrastructure. The broader product docs explicitly support automated documents, template-based generation, and HTML-based PDF rendering as core workflows.

When to use this recipe #

This workflow fits applications that need to generate structured PDF documents automatically from application data. The platform’s HTML-rendering model is designed for layouts, templates, and dynamically generated markup that can be turned into document output through an API call.

Example architecture #

Typical invoice-generation flow:

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

This reflects the documented Davix H2I interaction model: the client sends a request to the public API, the backend processing engine performs the render, and the result is returned to the calling system.

Step 1 — Create an invoice HTML template #

Invoices are a natural fit for the HTML-rendering workflow because they are typically structured layouts. Davix H2I accepts HTML layouts, templates, and dynamically generated markup as input.

Example invoice template:

<div style="font-family:Arial, sans-serif; padding:40px;">
  <h1>Invoice</h1>
  <p><strong>Invoice Number:</strong> INV-1024</p>
  <p><strong>Date:</strong> 2026-01-10</p>
  <hr>
  <h3>Billing Information</h3>
  <p>
    Customer Name<br>
    customer@example.com
  </p>
  <hr>
  <table style="width:100%; border-collapse:collapse; margin-top:20px;">
    <tr>
      <th style="text-align:left;border-bottom:1px solid #ccc;">Item</th>
      <th style="text-align:right;border-bottom:1px solid #ccc;">Price</th>
    </tr>
    <tr>
      <td>Monthly Subscription</td>
      <td style="text-align:right">$29.00</td>
    </tr>
    <tr>
      <td>Additional Usage</td>
      <td style="text-align:right">$10.00</td>
    </tr>
    <tr>
      <td style="text-align:right;font-weight:bold;">Total</td>
      <td style="text-align:right;font-weight:bold;">$39.00</td>
    </tr>
  </table>
</div>

In a real integration, the application would replace the example values with real invoice data before sending the request.

Step 2 — Send the PDF 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 returns JSON. This recipe uses the pdf action.

Authentication is accepted through:

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

In production, body-based api_key and query-based ?key= authentication are rejected, so public integrations should authenticate through headers.

Full example request #

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

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

Request parameters #

ParameterRequiredDescription
actionyesMust be pdf to generate PDF output
htmlyesHTML content to render
cssnoAdditional CSS injected into the render document
widthnoRender width
heightnoRender height
pdfFormatnoPDF page format
pdfLandscapenoLandscape orientation
pdfMarginnoPage margin
preferCSSPageSizenoUse CSS page-size preference
scalenoRender scale
printModenoPrint media emulation toggle
printBackgroundnoInclude CSS backgrounds in the PDF

Documented defaults for PDF mode:

  • pdfFormat: A4
  • pdfLandscape: false
  • pdfMargin: 24
  • preferCSSPageSize: true
  • scale: 1
  • printMode: false
  • printBackground: true

Example success response #

A successful request returns a generated output URL in this shape:

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

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

Output behavior #

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

Using the generated invoice #

After the API returns the generated PDF URL, the application can use that output in its own workflow. For example, it may:

  • store the returned URL
  • provide the file for download
  • pass the generated file to another system
  • use it inside a billing or account workflow

Davix H2I handles rendering and output generation. Downstream delivery is handled by the calling application.

Automation workflow #

A common automation pattern is:

Payment or billing event
        │
        ▼
Generate invoice data
        │
        ▼
Render invoice HTML template
        │
        ▼
Call Davix H2I API
        │
        ▼
Receive generated PDF URL
        │
        ▼
Use PDF 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 processing 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 limits doc uses render_too_large
  • external-facing error docs use render_size_exceeded

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

Summary #

This recipe shows how to generate invoice PDFs using Davix H2I’s HTML-to-PDF workflow.

The documented flow is:

  • generate an invoice HTML layout
  • send it to POST /v1/h2i
  • render the PDF through the H2I engine (PixLab)
  • receive a generated output URL in response
Was it helpful ?
Table of contents
Login
Login
Login
Login
Scroll to Top