The data is already typed. It is in the CRM, the applicant tracking system, the HR record. And yet somebody opens a PDF and types the same name, address and start date again, because the form is a fixed government or agency layout that nothing in the stack knows how to fill.
Most tools sold for this problem quietly solve a different one. There is a real and rarely-stated split between filling the fields of a PDF you already have and generating a new document that looks similar. If the form is a W-4, an I-9, or a lender's own template, only the first is any use — the layout is not yours to redesign.
If the PDF's layout is fixed and non-negotiable, you need something that fills its existing fields: Anvil over its API, a library like pdf-lib if you have a developer, or an AI filler for forms that vary. If you control the layout and just want the data merged in, Documint or PandaDoc generate documents from CRM records and do it well. Zapier and Make move the data but do not fill PDF fields with their own native steps — that takes a third-party app inside them.
The six approaches at a glance
| Approach | What it really does | Fills an existing PDF's fields | Needs code | Cost |
|---|---|---|---|---|
| Anvil | Turns your PDF into a hosted template, then fills it over an API | Yes — via a template derived from your PDF | Yes for the API; the dashboard needs none | Free plan is dashboard-only; metered filling from $0.10 per fill, AI Pack $99/mo |
| pdf-lib / PDFtk | Libraries that write values into AcroForm fields | Yes — directly, no hosted copy | Yes | Free (MIT / GPL v2; PDFtk redistribution licence $995) |
| Documint | Generates documents from CRM records against a template you design | Generation, not field-filling | No | $49 / $149 / $299 per month (200 / 1,000 / 5,000 documents) |
| PandaDoc | Proposal and contract workflow with CRM data merge | Partial — it detects existing AcroForm fields on upload and converts them into its own | No | Free plan; Starter $19, Business $49 per seat/month billed annually |
| Zapier / Make | Moves data between systems and triggers the step that does the filling | Not with native steps — needs a PDF app inside the platform | No | Zapier free 100 tasks/mo; Make from about $10.59/mo billed monthly |
| Filly AI | Reads any PDF with AI and fills it from a saved profile or a spreadsheet | Yes — including scanned PDFs with no field layer | No | Free plan, 10 fills/month; from $19/month |
Filling a PDF and generating a document are not the same product
This is the distinction worth getting right before you buy anything. Documint and PandaDoc are excellent at taking a record out of a CRM and producing a polished document from a template you designed. That is the correct tool for a proposal, a quote, a contract, an offer letter — anything where the layout is yours.
It is the wrong tool for a W-4. You cannot redesign a W-4. The form has to come back as the IRS's own layout with values in the IRS's own boxes, and a document generator has no opinion about where those boxes are. PandaDoc gets closest of the two: it detects existing AcroForm fields when you upload a PDF and converts them into its own fields, which is why the table above says partial rather than no — but the working model is still "bring it into PandaDoc," not "fill this file and give it back."
What Zapier and Make actually do here
Both get recommended for this constantly, and both are being recommended for the wrong half of the job. Zapier and Make are superb at the part before the PDF: noticing a new candidate in the ATS, pulling the record, mapping fields, passing them onward. Neither fills PDF form fields with its own native steps.
What they do have is other people's apps. PDF.co publishes a Zapier action to fill PDF form fields; PDF4me publishes a "Fill a PDF Form" module for Make. So "can Zapier fill a PDF?" is properly answered "yes, through an app inside it, which is a second tool with its own pricing" — not a flat no, and not the yes the marketing implies.
The API route, and its one catch
Anvil is the most direct answer for a team with a developer and a fixed set of forms. You upload the PDF, Anvil builds a template from it, and you POST JSON to fill that template and get the PDF back.
The catch is worth knowing before you plan around it: you are filling Anvil's template of your PDF, not the file itself. Data keys map to field aliases in that template rather than the PDF's own field names — and Anvil's own documentation notes that imported field names often arrive unhelpfully named. If a PDF has no fillable fields at all, Anvil says its system will not detect them and you draw the fields yourself, unless you use its Document AI. That is a one-off setup cost per form, which is fine for ten stable forms and painful for a hundred that change.
On price, be careful reading their pages: the free plan covers dashboard filling, while API access is metered from $0.10 per fill. Anvil's site currently carries a couple of figures that contradict each other, so confirm the rate against your own account before budgeting.
If you have a developer and the forms don't change
Nothing beats a library. pdf-lib (MIT, free) writes values into AcroForm fields from JavaScript; PDFtk Server (GPL v2, free, with a $995 licence if you redistribute it) does the same from the command line. No hosted copy of your documents, no per-fill fee, no vendor.
The cost is not the code — filling a known field is a few lines. It is that somebody has to map every field of every form, and re-map it when the agency reissues the form. That maintenance is invisible on day one and is the reason most teams eventually stop.
Where Filly fits, and where it doesn't
Filly reads the form with AI and works out which field wants which detail, so there is no field mapping to write or maintain, and it handles scanned PDFs with no field layer via OCR. Values come from a client profile you save once, or from a spreadsheet.
Being straight about the limits, because they decide whether it suits you at all: Filly has no public API and no live CRM or ATS integration. The path from a CRM is an export — get a CSV out of the system, upload it, and Filly maps the columns to the form's fields and returns one filled PDF per row as a ZIP. It is CSV only, not XLSX, and a run is capped at 5 rows on Solo and 20 on Pro. If you need a filled PDF produced automatically the instant a record changes in Salesforce, that is Anvil or a library, not Filly.
What it is good at is the case the API tools handle worst: forms that vary, arrive as scans, and need a human to check the values before anything is filed.
How to choose
- Fixed layout you don't control, and a developer: pdf-lib or PDFtk, or Anvil if you would rather not maintain the mapping.
- Fixed layout, no developer, forms that vary or arrive scanned: an AI filler such as Filly.
- Layout is yours, data lives in a CRM: Documint or PandaDoc.
- The data needs moving between systems: Zapier or Make, plus whichever of the above actually fills the file.
- A filled PDF the moment a record changes: an API — Anvil or your own code. No no-code tool does this properly today.
Frequently asked questions
Can Zapier fill a PDF form?
Not with its own native steps. It can run a third-party app that does — PDF.co publishes a "fill PDF form fields" action in Zapier, and PDF4me publishes a "Fill a PDF Form" module for Make. Budget for that app as a separate cost.
What if the PDF has no fillable fields?
Most tools stop here, because there is nothing to address. A library needs fields to write into; Anvil states that fields will not be detected on a non-fillable upload without its Document AI, and you draw them by hand. Tools that OCR the page and place values by position — Filly among them — are the ones that keep working on a scan.
Is a CSV export good enough, or do I need a real integration?
It depends entirely on frequency. Onboarding paperwork run weekly in batches is a CSV job, and a live integration would be over-engineering. A filled document that must exist within seconds of a status change is an API job, and a manual export will not do. If it is an API job, the developer comparison weighs pdf-lib and PDFtk against a hosted filling API, and is blunt about which one the field map makes cheaper.
Does any of this handle signatures?
PandaDoc and DocuSign are built around signature workflow. If you only need the filled form signed once by one person, most fillers include a link-based signature — worth checking before adding a second subscription. See the contracts comparison for that side of it.
How current are these prices?
Checked against each vendor's own pricing page in August 2026, and stated with the billing basis because several vendors show annual and monthly prices in the same place — DocuSign's developer plans are a good example, where the headline monthly figure is the annual-billing rate. Confirm against your own quote before committing.