HTML to PDF API for Invoices and Reports

Turn HTML invoice templates into paginated PDFs with controlled paper size, margins, headers, footers, and background graphics — plus cURL and JavaScript examples and a practical comparison with wkhtmltopdf and Puppeteer.

Julien Sobrier Founder & CEO March 15, 2026

Why teams still choose PDF for invoices and reports

PNG and JPEG screenshots are perfect for dashboards and Slack threads, but finance, legal, and operations teams overwhelmingly want printable, paginated documents. PDFs preserve typography, embed fonts when configured correctly, and open the same way on every machine. When you generate invoices, statements, or month-end packs from a web application, you are really asking for a deterministic print pipeline — not a casual screen grab.

An HTML to PDF API closes the gap between your templating layer (Handlebars, React, server-rendered HTML, or static HTML from a CMS) and a file you can email, archive, or drop into a document repository. The key is controlling the same variables a designer would tweak in a desktop browser: paper size, margins, header and footer templates, and whether background colors and images print.

From HTML templates to pixel-stable PDFs

Most production invoice flows follow the same pattern: merge data into an HTML template, render in a real browser engine, then call the print subsystem to emit PDF bytes. That is materially different from rasterizing a viewport to an image. PDF output understands page breaks, vector text, and selectable content — which matters for accessibility and downstream text extraction.

When you evaluate an API, insist on knobs that map to Chrome’s print capabilities:

Paper format — A4 vs Letter vs legal, plus explicit width/height when you need non-standard sizes.
Margins — top, right, bottom, left in physical units so templates align with postal windows and letterheads.
Headers and footers — repeating title blocks, page numbers, and legal disclaimers on every sheet.
Background graphics — enable when your brand relies on full-bleed color or watermarks; disable to save ink in internal copies.
Landscape and scale — for wide tables that refuse to reflow politely.

ScreenshotCenter exposes these controls on the dedicated PDF generation API product surface so you are not fighting undocumented headless flags.

Minimal request examples

Below are illustrative calls. Replace the URL, API key, and endpoint host with your project values.

cURL

curl -X POST "https://api.screenshotcenter.com/v1/pdf/create" \
  -H "X-API-KEY: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://billing.example.com/invoices/INV-2048/html",
    "format": "A4",
    "margin_top": "12mm",
    "margin_bottom": "14mm",
    "margin_left": "10mm",
    "margin_right": "10mm",
    "print_background": true,
    "display_header_footer": true,
    "header_template": "<div style=\"font-size:9px;width:100%;text-align:center;\">Acme Corp — Confidential</div>",
    "footer_template": "<div style=\"font-size:9px;width:100%;text-align:center;\"><span class=\"pageNumber\"></span> / <span class=\"totalPages\"></span></div>"
  }'

JavaScript (fetch)

const res = await fetch("https://api.screenshotcenter.com/v1/pdf/create", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-KEY": process.env.SCREENSHOTCENTER_API_KEY!,
  },
  body: JSON.stringify({
    url: "https://billing.example.com/invoices/INV-2048/html",
    format: "A4",
    print_background: true,
    display_header_footer: true,
  }),
});
const json = await res.json();
// Poll job status, then download PDF from the returned URL — same pattern as screenshots.

wkhtmltopdf, Puppeteer, or a managed API?

Many teams start with wkhtmltopdf. It is fast to prototype but runs an older rendering engine that diverges from modern CSS (flexbox gaps, nested transforms, variable fonts). Layouts that look perfect in Chrome often break silently in wkhtmltopdf — exactly where invoice templates hurt the most.

Running your own Puppeteer cluster gives you Chrome fidelity, but you still own patching, fonts, PDF queueing, retries, multi-region routing, and storage. That is a sensible choice at very large scale with dedicated platform engineers; it is expensive distraction for most product teams.

Approach	Rendering fidelity	Operational load	Time to production
wkhtmltopdf	Dated WebKit	Low single-host	Fast until CSS bites
Self-hosted Puppeteer	Excellent	High (fleet + queues)	Slow
Managed HTML→PDF API	Chrome-class	Offloaded	Fast

Securing the HTML your API renders

Invoices almost always include PII and payment identifiers. If your template URL is public, search engines and attackers can fetch the same HTML your PDF job renders. Prefer signed, time-limited URLs, session cookies injected through the API, or internal-only hosts reachable from the capture workers. The PDF pipeline should never be the only access control — treat it as a renderer, not an authentication boundary.

When templates live in object storage, version them immutably (INV_TEMPLATE_V3.html) so a regression in CSS does not silently change every PDF generated that week. Pair semantic versioning with API request logs so finance can answer “which template build produced this file?” without guesswork.