PDF generator API: what it is, how the options differ, and how to call one

What a PDF generator API does

You send a request with the document source and a few options; the service renders it with a layout engine it maintains and returns the PDF bytes. The engine is the whole product. Chromium-based services print exactly what Chrome would, so Flexbox, CSS Grid, web fonts and print CSS behave like the browser. Print-engine services such as Prince specialise in typography: footnotes, running headers, widows and orphans. Template services add a hosted design tool and take JSON instead of markup.

What you avoid: downloading a 200 to 400 MB browser into every environment, keeping it patched, handling zombie processes and memory growth under load, and the cold-start and bundle-size problems that come with serverless deployments.

API or library: when each wins

A library is right when the PDF must be produced with no network call, when data residency forbids sending documents to a third party, or when you draw documents from primitives rather than from HTML. ReportLab, fpdf2, PDFKit and @react-pdf/renderer are good at that job. An API is right when the document already exists as HTML, when you deploy to serverless platforms, when several languages in your stack need the same output, or when nobody on the team wants to own a Chromium fleet. The usual tipping point is the second production incident caused by the renderer rather than by your code.

Common uses

• Invoices and receipts rendered from the same template as the in-app view, attached to emails or stored for compliance. See the invoice guide.
• Reports and statements generated on a schedule: monthly usage, analytics summaries, account statements with charts.
• Customer exports: "Download as PDF" on dashboards, tickets, certificates, quotes and contracts.
• Archiving web pages by URL, for audit trails or snapshots of published content.
• Multilingual documents where right-to-left scripts, Arabic shaping or CJK fonts break lighter renderers. See the RTL guide.

The three kinds of PDF API, compared

Most "best PDF API" lists mix products that solve different problems. Sort them by what they take as input and the comparison gets simpler.

Vendor details change; the free-tier and pricing-model notes reflect public plan pages as of mid-2026. Head-to-head pages: DocRaptor, API2PDF, PDFShift, Gotenberg.

What to check before you pick one

• Rendering engine and version. Current Chromium renders what your front-end renders. Anything built on wkhtmltopdf is frozen on a 2012 WebKit.
• Input modes. HTML string, URL, or both. URL mode should refuse private and cloud-metadata addresses so it cannot be turned against your own network.
• JavaScript policy. Off by default is safer and faster; opt-in per request is the useful middle ground.
• Latency and cold starts. A warm browser pool answers in well under a second; services that spin up a browser per request do not.
• Fonts. Ask what ships for Arabic, Hebrew, Devanagari and CJK. Missing fonts render as boxes.
• Pricing unit. Per document is predictable. Per megabyte or per credit punishes image-heavy reports.
• Data retention. Documents often contain customer data. Prefer in-memory processing with nothing written to disk.
• Error contract. Stable error codes and a request ID you can quote to support save hours when something renders wrong.

How pricing models work

Per-document monthly tiers. A fixed fee covers a volume: pdfkitt is 1,000 PDFs/month free, then $19 for 10,000, $49 for 50,000 and $149 for 200,000 PDFs a month, with a 20% overage allowance before requests are blocked. DocRaptor uses the same shape with a 5-document free plan. Easy to forecast; you pay for the tier even in a quiet month.

Pay-as-you-go. API2PDF charges a fraction of a cent per conversion with no monthly minimum. Cheapest at very low or very spiky volume; the bill is harder to predict.

Credit or size metering. PDFShift counts credits by output size, so a 50-page image-heavy report costs more than a one-page receipt. Fine for uniform documents, awkward when they vary.

Generate a PDF with one request

The pdfkitt endpoint is a single POST. Send html or url, optional options for page size, margins, orientation and backgrounds, and get application/pdf back. Errors return JSON with a stable code, a message and a request_id. Render time is capped at 30 seconds.

curl

curl -X POST https://api.pdfkitt.dev/v1/convert \
  -H "Authorization: Bearer $PDFKITT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "html": "<h1>Invoice #1042</h1><p>Total: $49.00</p>", "options": { "page_size": "A4" } }' \
  --output invoice.pdf

Python

import os, requests

resp = requests.post(
    "https://api.pdfkitt.dev/v1/convert",
    headers={"Authorization": "Bearer " + os.environ["PDFKITT_API_KEY"]},
    json={"html": html, "options": {"page_size": "Letter", "landscape": True}},
    timeout=60,
)
resp.raise_for_status()
open("report.pdf", "wb").write(resp.content)

Node.js, rendering a URL with JavaScript enabled

const res = await fetch("https://api.pdfkitt.dev/v1/convert", {
  method: "POST",
  headers: {
    Authorization: "Bearer " + process.env.PDFKITT_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ url: "https://example.com/statements/2026-10", javascript: true }),
});
const pdf = Buffer.from(await res.arrayBuffer());

C#

using var http = new HttpClient();
http.DefaultRequestHeaders.Authorization = new("Bearer", Environment.GetEnvironmentVariable("PDFKITT_API_KEY"));

var body = JsonContent.Create(new { html, options = new { page_size = "A4" } });
var res = await http.PostAsync("https://api.pdfkitt.dev/v1/convert", body);
res.EnsureSuccessStatusCode();
await File.WriteAllBytesAsync("invoice.pdf", await res.Content.ReadAsByteArrayAsync());

Language guides with framework examples: Python and Django, Node.js, PHP and Laravel, Java and Spring, C# and .NET, React and Next.js, serverless.

Try it with your own HTML

curl https://api.pdfkitt.dev/v1/convert \
  -H "Authorization: Bearer pdfk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"html":"<h1>Hello, world!</h1>"}' \
  --output document.pdf

FAQ