Creating PDFs from Dynamic Content

Overview #

Davix H2I supports rendering HTML into PDF documents through POST /v1/h2i with action=pdf. In this workflow, your application builds the HTML for the document, sends it to Davix H2I, and receives a generated PDF output URL in response. The rendering work is performed by the H2I engine (PixLab) behind the Davix H2I product layer.

HTML-to-PDF rendering is one of the platform’s core capabilities. It allows applications and automated systems to turn dynamic HTML content into document output without operating their own rendering infrastructure.

How the workflow works #

The HTML-to-PDF workflow is:

1. Your system creates HTML representing the document.
2. Your system sends the HTML to POST /v1/h2i.
3. The request is authenticated with an API key.
4. The request sets action to pdf.
5. PDF-related render options are included as needed.
6. The H2I engine (PixLab) renders the PDF file.
7. The API returns a JSON response containing a generated output URL in url.

Endpoint used #

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

The /v1/h2i endpoint is the public HTML-rendering endpoint. It accepts JSON and URL-encoded bodies and supports both image and pdf actions. This guide covers the pdf workflow specifically. This is separate from /v1/pdf, which is the multipart PDF-processing endpoint for uploaded PDF files.

Authentication #

External /v1/* routes accept authentication 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 with api_key_location_not_allowed, so public integrations should always authenticate through headers.

Required parameters #

For HTML-to-PDF generation, the request requires:

• action — must be pdf
• html — the HTML source to render

Optional PDF-related parameters include:

• css
• width
• height
• pdfFormat
• pdfLandscape
• pdfMargin
• preferCSSPageSize
• scale
• printMode
• printBackground

Response format #

A successful request returns this shape:

{
  "url": "https://pixlab.davix.dev/h2i/<generated-file>",
  "request_id": "<REQUEST_ID>"
}

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

Example 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>Invoice</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 is the documented full public example for the /v1/h2i PDF action.

Example success response #

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

H2I-generated outputs are served through the /h2i/* output path, and file-producing routes return signed URLs through the platform’s signed output system.

Parameter reference for this workflow #

Field	Required	Type	Notes
action	yes	string	Must be pdf
html	yes	string	HTML source to render
css	no	string	CSS injected into the render document
width	no	integer-ish	Defaults to 1000
height	no	integer-ish	Defaults to 1500
pdfFormat	no	string	Defaults to A4; only LETTER maps to Letter, otherwise A4
pdfLandscape	no	boolean / string	Defaults to false
pdfMargin	no	integer-ish	Defaults to 24
preferCSSPageSize	no	boolean-like	Defaults to true
scale	no	float-ish	Defaults to 1
printMode	no	boolean-like	Defaults to false
printBackground	no	boolean-like	Defaults to true

These defaults and behaviors come from the external /v1/h2i API reference.

Notes on PDF rendering behavior #

The documented PDF mode supports two main patterns:

• using raw HTML content as the source document
• adjusting output behavior with page and print-related parameters such as page format, landscape mode, margin, CSS page-size preference, scaling, and background rendering

This makes the route suitable for document-generation workflows where the source content is already produced as HTML by your application. The broader product documentation also describes HTML-to-image and HTML-to-PDF rendering as one of Davix H2I’s defining capabilities.

Important behavior #

The /v1/h2i route applies the same H2I route enforcement layers for PDF rendering as it does for image rendering, including:

• API key authentication
• endpoint gating where applicable
• timeout handling
• concurrency control
• HTML size checks
• render-size controls
• customer quota handling

The canonical limits documentation shows that H2I rendering is controlled by runtime-configured values for:

• maximum HTML length
• maximum render width
• maximum render height
• maximum render pixel area
• request timeout

For public-facing documentation, this page should not repeat numeric limit values if your limits are being centralized under Errors and Limits. Link users to that page instead of duplicating numbers here.

One important implementation detail from the canonical limits doc is that width and height are clamped to configured render ceilings, while pixel-area overflow is rejected.

Errors you may encounter #

Relevant documented 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
• html_render_failed
• authentication and idempotency errors such as invalid_api_key, key_expired, api_key_location_not_allowed, and invalid_idempotency_key

For render-size limit failures, the loaded docs are not fully aligned:

• the cURL reference says render_size_exceeded
• the canonical limits doc says render_too_large for H2I pixel-area overflow

Because of that mismatch, this page should use neutral wording such as “render-size limit error” unless you first unify the source documentation.

Example error response #

{
  "status": "error",
  "code": "html_too_large",
  "message": "HTML payload exceeds allowed limit",
  "error": {
    "code": "html_too_large",
    "message": "HTML payload exceeds allowed limit"
  },
  "request_id": "<REQUEST_ID>"
}

This matches the standard JSON error envelope used across the external API surface. Public docs should treat request_id as typically present, not as an absolute guarantee in every success example.

When to use this guide #

Use this workflow when your system needs to convert dynamically generated HTML into a PDF document through an API call. This is one of the main rendering patterns supported by Davix H2I and one of the foundational uses of the platform’s HTML-rendering capability.