Generate a PDF from Zapier, Make or n8n: the three approaches, compared

A deal closes in your CRM and somebody needs a signed order form. A form gets submitted and somebody needs a branded confirmation. A row lands in a spreadsheet and somebody needs a certificate with a name on it. In every one of these, the automation platform is already running the workflow and the only missing piece is the document.

None of the big automation platforms generate PDFs on their own. Zapier, Make and n8n all move data between apps; turning that data into a designed document is somebody else's step. There are three ways to add that step, they suit different teams, and the one you pick determines how much of the work lands on an engineer.

The short version

To generate a PDF in Zapier, Make or n8n you add one of three kinds of step. A dedicated PDF app with a native integration is the fastest route if nobody on the team writes code: you design a template in the vendor's dashboard, map fields into it, and the PDF comes back in the workflow. A webhook or HTTP step calling an HTML to PDF API is the right choice when your application already renders the document, or when the thing you want captured is a page that already exists at a URL. A Google Docs template copied and exported to PDF is the cheapest option and works well for simple, text heavy documents. All three return a file or a link that a later step files, emails or uploads.

Option 1: a dedicated PDF app with a native step

This is what most teams reach for first, and for non technical teams it is usually correct. Services like PDFMonkey, APITemplate.io, CraftMyPDF and DocSpring exist specifically to be a step in an automation. You build a template in their editor once, define the variables it expects, and the platform gives you a step where each variable becomes a field you can map from an earlier step.

What you are buying is the mapping interface. Without it, sending structured data to a document service means hand writing a JSON payload inside an automation step, which is exactly the kind of task that stops being no-code. A native app turns that into a form.

The limits are worth knowing before you commit. The template lives in the vendor's dashboard, not in your repository, so it sits outside code review and outside your release process. Most of these services meter by generated document and delete the output on a retention clock, so a workflow that needs the file six months later has to store it somewhere else. And none of them render an arbitrary live URL: they fill their own templates, which matters if the document you want is a page your app already produces. We wrote up that trade in more detail on the PDFMonkey alternative page, including where PDFMonkey is the better tool.

Option 2: an HTTP step calling an HTML to PDF API

Zapier has Webhooks by Zapier, Make has the HTTP module, and n8n has the HTTP Request node. Any of them can call a rendering API directly, which opens up two things the template services cannot do.

The first is rendering a page that already exists. If your app has a page at /invoices/1234 that already shows the invoice correctly, you do not need to rebuild it as a template anywhere. Point the render call at that URL and you get the document you were already displaying. That is the workflow on the URL to PDF API page, and it removes an entire class of maintenance, because the invoice layout stops existing in two places that have to be kept in sync.

The second is that your HTML stays in your codebase. Designers and engineers edit the template the way they edit everything else, changes go through pull requests, and the automation platform only carries data.

The cost is setup. You configure the request yourself: a POST, an authorization header holding your API key, and a body containing either a URL or the HTML. Zapier's custom request mode wants raw JSON, so somebody who is comfortable with an API call needs to build it once. After that it is a step like any other, and non technical teammates can duplicate the Zap without touching it again.

Two details save time here. Set the response handling so the step returns a file rather than a blob of text, because the next step almost always wants an attachment. And if the page renders anything asynchronously, charts, fonts, data loaded after the initial paint, tell the renderer what to wait for instead of hoping. Waiting for content correctly is the difference between a finished document and a half drawn one.

Option 3: the Google Docs route

There is a genuinely free path that gets overlooked. Build the document as a Google Doc with placeholder text, then in the automation copy the file, replace the placeholders with data, and export the copy as a PDF. Zapier, Make and n8n all have Google Drive and Google Docs steps that do these pieces.

For a letter, a simple agreement, a memo or an offer, this works and costs nothing beyond a Workspace seat you already pay for. It stops working when the layout gets specific. Tables that grow with the number of line items, precise page breaks, headers repeating across pages, exact brand typography: those are painful or impossible in a document built for text editing. It is also several steps rather than one, so it uses more of your task or operation quota per run.

Which one to pick

	Dedicated PDF app	HTML to PDF API	Google Docs export
Setup difficulty	Low, it is a form	Medium, one API call to configure	Low to medium, several steps
Who maintains the template	Anyone, in the vendor dashboard	Whoever owns the codebase	Anyone, in Google Docs
Renders a page that already exists	No	Yes	No
Complex layout and precise page breaks	Good	Good, full CSS	Weak
Line items that vary in length	Good, loops in the template	Good, an HTML table	Awkward
Marginal cost per document	Metered per document	Metered per render	Free, uses more tasks
Where the output is stored	Vendor, often on a retention clock	Wherever your workflow puts it	Google Drive

The parts that break

Whichever route you take, the same four things go wrong, and none of them are about rendering.

Expiring links. Most PDF steps hand back a temporary download URL rather than the file itself. If you store that URL in a CRM field and call it done, you have saved a link that will stop working. Download the file inside the same run and put it somewhere permanent: Drive, S3, the record itself as an attachment.

Files versus text. Automation platforms distinguish between a file object and a string. A step that returns raw bytes as text will attach a broken PDF to an email, and the failure looks like a rendering problem when it is a data type problem. Check that the step is actually emitting a file before you debug the document.

Quotas that multiply. Every step in a run counts. A workflow that generates a document, downloads it, uploads it and emails it is four operations, not one, and the document service meters separately from the automation platform. Do the arithmetic at your real monthly volume before picking a plan. If the volume is genuinely high, moving the loop into your own code is usually cheaper than running it as thousands of automation tasks; the bulk HTML to PDF page covers that shape, and what these APIs actually cost normalizes the different billing models.

No record of what you sent. This one surfaces months later. The workflow generated a quote, emailed it, and moved on. When the customer disputes a number, the file may still exist but nothing records what the source looked like at the moment it was generated. If the documents you are producing could ever be contested, capture a timestamped snapshot alongside the PDF rather than reconstructing it afterwards from data that has since changed.

Should the workflow generate the PDF at all?

Sometimes the honest answer is no. If the document is produced on a fixed schedule rather than in response to an event, a scheduled job in your own application is simpler, cheaper and easier to debug than a scheduled automation calling three services. That pattern is covered in the scheduled PDF reports guide.

And if the document exists to be signed, generating it is only the first half of the job. The step that usually follows is routing it to the people who need to sign and return it, which every one of these platforms can trigger once the file exists. Deciding where the document goes next often tells you which generation route to pick, because a service that deletes the file after a day is a poor fit for anything that has to come back countersigned.

Common questions

Can Zapier create a PDF by itself? No. Zapier has no built in PDF generation action. It moves data between apps, so producing a document requires either an integrated PDF app, a Webhooks by Zapier step calling a rendering API, or a Google Docs copy and export sequence. The same is true of Make and n8n.

How do I convert a URL to a PDF in Zapier? Use a Webhooks by Zapier step to POST the URL to an HTML to PDF API and return the file. Template based PDF apps cannot do this, because they render their own stored templates rather than arbitrary pages. Make it a file response so the following step can attach or upload it directly.

What is the cheapest way to generate PDFs in an automation? The Google Docs template and export route, since it needs no extra subscription. It costs more automation tasks per run and struggles with precise layouts, so it fits simple text documents. Past a few hundred documents a month with real formatting, a metered PDF service or API is usually cheaper overall once you count the task consumption.

Can n8n generate PDFs without a paid service? Yes, if you self host. n8n can run a Code node or call a self hosted renderer such as Gotenberg on your own infrastructure, which removes the per document fee and leaves you maintaining the service. That trade is laid out on the Gotenberg alternative page.

Where to start

If nobody on your team writes code, start with a dedicated PDF app and its native step. You will have a working document in an afternoon and that is worth a lot.

If your application already renders the document, or the thing you want is a page that exists at a URL, use an HTTP step against a rendering API instead. It is one more hour of setup and it removes the duplicate template you would otherwise maintain forever. You can paste a URL into the converter on our homepage to see what the rendered output looks like before wiring anything up.