Document Generation API: Automated PDF Document Generation Software

We re-read every rate card on this page on 30 August 2026. Four of the six template merge vendors had changed something, and two of the changes move in opposite directions, which is the interesting part.

Docmosis started publishing the number it used to withhold. In July, self-hosted Tornado was sold as a perpetual license with no amount printed. It now carries a full four tier ladder, $3,795, $6,695, $9,995 and $17,145, with 12 month renewals against each, and the cloud tier resolved from a vague "from $49" into three named plans at $49, $64 and $78 that differ by users and environments rather than by page allowance. Its pricing page dates itself to 1 June 2026. Note the URL moved too: docmosis.com/pricing.html now returns 404 and the page lives at /pricing/.

Docusign went the other way. The $20 per user a month figure for Gen for Salesforce, which is repeated across most comparison articles about this category, appears on no Docusign page we could find. Docusign's own plans page lists Gen only inside the feature table for Enhanced plans, marked Contact sales. We have removed the figure rather than keep printing something we cannot source, which is the same rule we apply to every row here.

Carbone re-denominated into US dollars and added two tiers. Essential Plus at $95 and Advanced Plus at $295 now sit between the plans that existed in July, and an AWS Marketplace route bills per document from $0.15 down to $0.008 at volume. Annual billing takes roughly 10 percent off.

Foxit moved its credit allowances substantially. Startup went from 3,500 to 5,000 credits at the same $1,750 a year, and Business now shows 15,000 credits at $4,500, with a custom Volume tier above it. That changes the shape of the ladder enough that our previous note about a cliff between the two paid tiers no longer describes it, so we have removed that too.

Conga still publishes nothing, and its pricing page still describes an intention to provide clear cost details without providing any. That is a null result and we are reporting it, because a category page that only records movement quietly implies the vendors it does not mention were checked and found unchanged. They were checked. Two of them had not moved.

Every other question in this category is downstream of one thing. Ask who changes the wording when it needs to change.

If the answer is Legal, Finance, Sales Ops, or anyone who does not open a code editor, you want template merge. Someone opens a .docx, edits clause 7.3, saves it, and the next document generated says the new thing. No ticket, no deploy, no engineer. That single property is why Conga, Docmosis and Adobe own the phrase "document generation software" and why they deserve to.

If the answer is engineering, template merge starts working against you. The template becomes a binary artifact sitting in a vendor dashboard or a Salesforce record, outside version control. Nobody can diff it, nobody reviews it, and six months later the question "who changed the contract template and when" often has no answer. Rendering HTML puts the document back where your team already works: in the repository, in code review, in staging before production.

We sell the other approach, so take this as a list of reasons not to buy from us.

• The output has to be editable. A contract that gets redlined needs DOCX out. HTML renderers cannot do that at all. Not slowly, not badly: not at all.
• A business user owns the content. Covered above, and it is decisive.
• The trigger lives inside Salesforce. If the workflow is a rep clicking a button on an Opportunity, Conga and Docusign Gen hand you record access, field-level permissions and audit inside the platform. Rebuilding that against a generic REST API means building the Salesforce half yourself.
• Long regulated documents with hundreds of conditional clauses. Insurance policies and loan agreements maintained by compliance rather than engineering are a template-merge problem.
• You need Word, Excel and PowerPoint from one engine. Carbone and Apryse Fluent do this. We do not.

One vertical worth calling out separately: law firms. The products sold into legal drafting are a different set of vendors with a different meter, and most of them will not tell you the price without a call. We mapped that market, including which two of eight publish a rate card, on legal document automation software.

The flip side is just as concrete.

• The document already exists as a web page. Invoices, statements, receipts, order confirmations, dashboards. You have the HTML. Re-authoring it as a Word template creates a second copy that will drift from the first.
• Design fidelity. Flexbox, grid, web fonts, SVG, charts, your existing brand CSS. A Word template cannot express a designed report, and everyone who has tried to force it knows the feeling.
• Templates in version control. Diffs, review, staged rollout, per-environment testing, and a real answer to who changed what.
• One deterministic engine. Word and LibreOffice do not lay out identically, which is a live source of support tickets in merge-based systems. A single managed Chromium build renders the same everywhere.

If your stack is already pointed this way, the framework guides go deeper: Laravel, Next.js, Django, Spring Boot and Rails.

Plenty of teams end up running both, and that is a reasonable answer rather than a failure to decide: template merge for contracts that get negotiated, HTML rendering for the system-generated invoices and statements your product emits by the thousand.

Read the docs for Adobe, Foxit, Docmosis and Carbone and you will notice something they share: the render is stateless. Data goes in, a file comes back, and the service forgets it happened. The generated document is treated as output, not as a record.

The two HTML-rendering vendors that do store documents charge for the privilege, which tells you how the category prices memory. PDFMonkey keeps generated files for one day on Free and Starter and seven days on Pro, with unlimited retention starting on its 60 euro plan. DocRaptor sells document hosting as a separate add-on product.

That is backwards for anyone whose documents matter after they are sent. If a customer disputes an invoice in March, the question is not whether you can generate a fresh PDF today. It is what the document said when it went out, and whether you can produce it. Sitepdf answers that by making the archive part of the same call: set archive=true and the render is kept as a timestamped snapshot you can retrieve by id later. The website archiving page covers the record-keeping side in full, the security guide covers what a review board will ask before you can buy any of this, and accessible PDF generation covers the other question that arrives with public sector buyers, whether the documents you produce are readable by assistive technology.

Choosing an engine is half the project. The other half is what fires it. In practice there are four patterns: on-event (checkout completes, so render the receipt), on-demand (a user clicks Download), batch (month end, render 40,000 statements), and scheduled (every Monday, render and email the report). A fifth exists wherever the output has to arrive on paper, a statement or a statutory notice handed to a print and mail API, and the per piece economics of that leg are worked out in our direct mail API pricing comparison. Each has a different failure mode, and the guide on how to automate PDF generation walks through all four with the specific things that break in each. For the month-end case, bulk HTML to PDF covers concurrency and retries, and scheduled PDF reports covers the recurring pipeline. If your trigger lives in a no-code tool, generating PDFs from Zapier, Make and n8n is the practical path.

Before you commit to a vendor, run the numbers rather than the list price. Billing models in this category are not comparable at face value: Adobe counts one document transaction per API call regardless of output length, Carbone counts one document per megabyte of injected data so a 2.3MB payload bills as three, and Foxit sells credits by the year. Normalizing these into cost per thousand documents is the only way to compare them, and it routinely changes the ranking.