n8n

PDF generation in n8n

No code at all — but the binary-data handling is specific enough to n8n that getting it wrong produces a corrupt file with no error, which is worth one page.

The code

// HTTP Request node
{
  "method": "POST",
  "url": "https://api.pdfcraft.dev/v1/render",
  "authentication": "genericCredentialType",
  "genericAuthType": "httpHeaderAuth",
  "sendBody": true,
  "specifyBody": "json",
  "jsonBody": "={{ JSON.stringify({ html: $json.html, options: { printBackground: true } }) }}",

  // The two that matter:
  "responseFormat": "file",
  "outputPropertyName": "data"
}

// Then a Write Binary File or Send Email node consumes {{ $binary.data }}.

What to watch for

`responseFormat: "file"` is essential. Left as `json`, n8n tries to parse the PDF as JSON, fails, and hands the next node a broken string rather than an error.
Store the key as an HTTP Header Auth credential (`Authorization: Bearer sk_live_…`), not inline in the node — inline values appear in every execution log.
For batches use `output: "url"` and let the next node fetch the signed URL, so a long workflow is not carrying megabytes of binary between steps.

Why not run the browser yourself

You can. Puppeteer and Playwright both work, and for a script you run by hand they are the right answer. The cost arrives at the point it becomes a service someone depends on: one long-lived browser per process rather than one per request, a semaphore so four renders do not become forty, a hard timeout that force-closes a hung page before it holds a slot forever, a scheduled restart because Chromium leaks, and a Chromium version you are now responsible for patching.

None of that is hard. All of it is work that has nothing to do with your product, and it fails under concurrency rather than in testing — which is the worst time to discover it.

PDF generation in n8n

The code

What to watch for

Why not run the browser yourself

Other frameworks

Or by language