Fill PDFs With Node.js — JSON-to-PDF API for JavaScript Backends

Filling a PDF programmatically from Node.js looks easy until the first edge case. The pdf-lib approach works for trivial forms but breaks on radio groups, checkbox encoding variants, and AcroForm flattening. PDFKit is for generating PDFs from scratch, not filling existing fillable forms. The Puppeteer + headless Chrome approach renders an HTML overlay onto a PDF but ships a 200MB browser, breaks on scaled layouts, and is hard to deploy on serverless platforms.

The DullyPDF API is a thin layer over the same field-detection and fill engine the web product uses. The Node.js call is one HTTPS POST. No SDK, no native bindings, no font shipping. The PDF is detected and the field map is frozen at template publish time, so the JSON contract is stable across deployments.

A typical call from a Node.js backend looks like the snippet below. The endpoint URL and API key come from the API Fill modal in the DullyPDF workspace after you publish a saved template. The JSON body uses three top-level keys: a `data` object whose keys are the cleaned field names from your saved template, an `exportMode` flag (`"flat"` returns a non-editable PDF, `"editable"` keeps the AcroForm intact), and a `strict` boolean (set true so unknown payload keys are rejected instead of silently ignored).

Authentication is HTTP Basic with the API key as the username and a blank password — equivalent to sending `Authorization: Basic base64(API_KEY + ":")`. The response body is the raw PDF.

• import { writeFile } from "node:fs/promises";
• const apiKey = process.env.DULLYPDF_API_KEY;
• const auth = `Basic ${Buffer.from(`${apiKey}:`).toString("base64")}`;
• const res = await fetch("https://api.dullypdf.com/api/v1/fill/<TEMPLATE_ID>.pdf", {
• method: "POST",
• headers: { "Content-Type": "application/json", Authorization: auth },
• body: JSON.stringify({ data: { patient_name: "Jane Doe", patient_email: "jane@example.com" }, exportMode: "flat", strict: true }),
• });
• if (!res.ok) throw new Error(`fill failed: ${res.status} ${await res.text()}`);
• await writeFile("./filled.pdf", Buffer.from(await res.arrayBuffer()));

The Node.js teams that get the most out of an external PDF fill API tend to share a shape. They have an existing CRUD or workflow app where the user has just submitted a form, finished an order, completed a benefits enrollment, or signed a contract. They need to render that record into a specific PDF — an ACORD certificate, an HR onboarding packet, a fillable government form, a generated invoice — and either email it, store it, or hand it back to the user.

In that shape, every native PDF library forces you to think about field positions, font embedding, encryption, and AcroForm internals. An external API replaces that with one HTTPS call and a JSON payload that mirrors the database row you already have. That removes most of the surface area where in-house PDF code goes wrong.

• Insurance back-office: render a filled ACORD 25 from the policy record after binding.
• HR / staffing: render a populated I-9 + W-4 packet on hire-confirmed.
• Healthcare-adjacent (non-PHI): render an intake summary PDF for the customer record.
• Internal ops: scheduled job renders 50 filled certificates from yesterday's submissions.

There is a place for in-process PDF libraries. If you control the source PDF and the form is trivial — a single page with a handful of named text fields and no checkboxes or radios — pdf-lib is fine. If you are generating a PDF from scratch and never touching an existing fillable template, PDFKit is the right tool. The DullyPDF API is the right tool when the source PDF is non-trivial, the field set needs detection, or the same template is going to be filled by more than one caller from more than one runtime.

• pdf-lib: good for trivial AcroForms, weak on radio groups + checkbox variants + flattening.
• PDFKit: PDF generation from scratch, not fillable-form filling. Different tool category.
• Puppeteer + Chrome: works but ships a browser, slow cold start, hard on serverless.
• DullyPDF API: one HTTPS POST, no native deps, template-scoped schema, field detection done once.

Because the API is a single HTTPS endpoint, every Node deployment shape works without extra setup. From a long-running Express server, the call is fetch + write to disk. From a Next.js Route Handler the same fetch returns a Response that streams straight back to the browser. AWS Lambda, Google Cloud Functions, Cloudflare Workers, and Vercel Edge all work because there are no native dependencies to ship in the bundle. Cold starts stay fast because no PDF library has to be loaded into memory on the calling side.

The free tier covers prototypes and low-volume production. Once you cross the request quota, the single Premium tier raises the limits without a separate plan negotiation. The published endpoint and field schema do not change when the plan changes — only the quotas do. That means scaling up does not force a code change.