Buyer’s guide

The best PDF API for auto-filling government compliance forms is the wrong first question

Every guide on this compares PDF-fill APIs against each other. That comparison only matters once you already hold clean data. For compliance forms spread across an organization, the data lives in legacy systems that have no API, and the finished form has to be submitted into a portal. A PDF API does neither. This guide draws the line so you buy the right tool, or the right two tools.

M
Matthew Diakonov
8 min read

Direct answer (verified 2026-06-16)

There is no single best PDF API, because the keyword hides two jobs. Pick by your actual bottleneck:

  • You already hold clean, structured data and just need to render filled PDFs at scale, then a dedicated PDF-fill API is right: Anvil, Apryse, Nutrient, pdfRest, or, for a free self-hosted option built for government, the MIT-licensed GSA/pdf-filler.
  • The field data lives in legacy desktop systems (SAP, Epic, Jack Henry, a mainframe) and the form has to be submitted into a government portal, then a PDF API solves neither. That is a desktop-automation job, and it is the part this page is about.

Auto-filling a compliance form is three jobs, not one

When a team types “best PDF API” into a search box, they usually picture a single step: data goes in, completed PDF comes out. That is real, and it is the step PDF APIs are excellent at. But “across our organization” and “government compliance” quietly add two steps on either side, and those are where the work actually piles up.

What 'fill the form' really means at organization scale

1

Gather the field values

Read the right record out of SAP GUI, Epic, Jack Henry, or a mainframe. Often no usable API exists.

2

Fill the PDF

Stamp the values into the AcroForm fields. This is the part a PDF-fill API does well.

3

Submit into the portal

Log into the state or federal portal and lodge the completed form. Usually another app with no bulk API.

The PDF API owns the middle step. If your data is already clean in a database, the two side steps disappear and the PDF API really is the whole answer. For most organizations running compliance at volume, the data is not in a database. It is on a screen in an app someone has to click through, and that is what changes the buying decision.

Drawing the line precisely

What a PDF-fill API does well

  • Take a JSON object of field values and write them into the PDF's AcroForm fields
  • Flatten the result so it cannot be edited after signing
  • Return the completed PDF as a download over HTTP
  • Do all of the above at high volume once the data is already clean

What no PDF-fill API does

  • Open SAP GUI and read the vendor master record the form needs
  • Pull a value out of an Epic registration screen that has no documented API
  • Wait for a mainframe green screen to finish a save before reading the next field
  • Log into a state government portal and submit the completed form
  • Re-find a field after the source app gets a vendor upgrade

This is not a knock on PDF APIs. It is their design. The clearest proof is the government’s own tool. The General Services Administration publishes GSA/pdf-filler under the MIT license. Its README calls it “a RESTful service to aid in the completion of existing PDF-based forms,” and it is explicit that you submit form values and receive the completed PDF. It is the final step in a workflow. It does not gather upstream data. The part most organizations are actually stuck on is upstream.

Where the value actually comes from

The PDF wants a vendor tax ID, a patient identifier, an account number. Those live in apps that predate the idea of an API. The missing layer reads the value off the live screen the same way a screen reader does, then hands clean data to whatever renders or submits the form.

Read the field, then hand it to the PDF API or the portal

SAP GUI
Epic / Cerner
Jack Henry / Fiserv
Mainframe terminal
Read the field value
PDF-fill API
Government portal

This is the layer Mediar owns. It is not a PDF library and it does not try to be one. It is a Windows desktop agent that reads and writes fields through OS-level accessibility APIs, so it works on the legacy systems where the data is trapped. Read more on why legacy desktop apps with no API are the hard case.

How the field actually gets written, in the source

The uncopyable detail here is that filling a field in a legacy app is a single, named primitive, not a pile of pixel coordinates. In the product source, the runtime emits a tool call named type_into_element, defined in apps/desktop/src-tauri/src/mcp_converter.rs at lines 2298 and 2460. It locates the matching accessibility node in the live tree and sets its value, with a keystroke fallback when a control does not expose an edit pattern. When the source app or portal changes, the runtime resolves the element through a four-strategy cascade in apps/desktop/src-tauri/src/focus_state.rs: automation id, then window plus bounds, then visible text, then the parent window as a fallback.

verify it yourself against the open-source SDK

Three of those four strategies do not depend on absolute position, so a routine layout change on a government portal does not quietly write the right value into the wrong field. The execution layer is published as the open-source Terminator SDK at github.com/mediar-ai/terminator, so a reviewer can confirm all of this directly.

Pick by your bottleneck

Your situationWhat to buy
Data already clean in a database; you only need filled PDFs at volumeA PDF-fill API (Anvil, Apryse, Nutrient, pdfRest, DocSpring), or GSA/pdf-filler if you want free and self-hosted
Forms are scanned, not fillable, but you still have the valuesA PDF API that overlays by position (GSA/pdf-filler, pdfRest); the data side is still solved
Field values live in SAP, Epic, Jack Henry, or a mainframe with no APIDesktop automation to read the values, then hand them to a PDF API
Completed form must be submitted into a state or federal portal with no bulk APIDesktop automation for the submission step; a PDF API cannot log in or click submit
Both ends are legacy and you want one auditable pipeline across the organizationMediar for the boundary work, optionally with a PDF API in the middle for rendering

When a PDF API really is the whole answer

To be fair to the question: if your organization has already done the integration work and your compliance data sits in a clean warehouse or a modern system with a real API, then you do not need any of the desktop layer. Wire your data source to Anvil or Apryse, map the fields once, and you are done. A PDF API is also the right call when the “submission” is just emailing or storing the PDF rather than driving a stateful portal. The desktop-automation argument only wins when an app with no API sits on one or both ends of the pipeline. For a lot of regulated organizations, it does, which is why this page exists.

Tell us where your form data is actually stuck

On a 20-minute call we map your form pipeline end to end and tell you honestly whether a PDF API alone covers it or whether the legacy desktop boundary is the real blocker.

Frequently asked questions

So what is the best PDF API for auto-filling government compliance forms?

There is no single best, because the question hides two different jobs. If you already hold clean structured data and you only need to stamp it onto a PDF at scale, a dedicated PDF-fill API is the right tool: Anvil, Apryse, Nutrient, pdfRest, and DocSpring all do this well, and the US government's own GSA/pdf-filler does it for free under MIT. If the data you need is locked inside legacy desktop systems and the completed form has to be submitted into a government portal, a PDF API solves neither of those, and the bottleneck is desktop automation, not PDF rendering.

Why can't a PDF API just read the data from our systems too?

Because that is not what a PDF library is built for. A PDF-fill API takes a payload of field values and writes them into the document's form fields. The GSA's own open-source filler describes itself in its README as the final step in a workflow: it accepts pre-existing data and populates the form. It does not, and is not meant to, open SAP GUI, navigate an Epic registration flow, or log into a state portal. Those are separate, much harder problems that involve apps with no usable API.

Our forms are scanned, not fillable. Does that change the answer?

It changes which PDF API can help, not the underlying split. Some APIs (including GSA/pdf-filler) overlay data onto non-fillable scanned PDFs by position. But that still assumes you already have the values. The hard part for an organization-wide deployment is rarely whether the PDF has AcroForm fields; it is getting the right values out of the systems of record and getting the finished form into the right destination.

How does Mediar actually write a value into a legacy app?

Through the Windows UI Automation accessibility framework, the same interface a screen reader uses. The runtime emits a single tool call named type_into_element, defined in apps/desktop/src-tauri/src/mcp_converter.rs at lines 2298 and 2460 in the product source. It takes a structured locator, finds the matching accessibility node in the live tree, and sets its value through the control's edit pattern, or falls back to keystroke simulation if the control does not expose one. There are no pixel coordinates and no image matching, so the same primitive works in SAP GUI, Epic, Cerner, Jack Henry, Fiserv, Oracle EBS, and terminal emulators that expose an accessibility tree.

What happens when a government portal or source app gets redesigned?

The runtime walks a four-strategy element-resolution cascade in apps/desktop/src-tauri/src/focus_state.rs. It tries the recorded automation id first, then the window plus bounds, then the visible text content, then the parent window as a last fallback. Three of those four do not depend on absolute pixel position, so a routine layout change (a panel reorders, a field moves down a row) usually resolves without anyone touching the workflow. This is why a UI change does not silently produce a wrong-field fill the way a brittle selector or a pixel matcher can.

Is Mediar a replacement for a PDF API, or do they work together?

They work together. If your end artifact is a filled PDF, you can let a PDF-fill API render it and let Mediar do the two things the PDF API cannot: gather the field values from the legacy desktop apps that hold them, and drive the submission into the portal. Treating Mediar and a PDF API as competitors is the most common category error here. The PDF API owns the document; Mediar owns the boundary with apps that have no API.

Is any of this auditable for a compliance team?

Yes. The model that authors a Mediar workflow runs once, during the offline recording pass, and writes a deterministic file. The runtime executor has no inference library in the hot path, which a reviewer can verify with a single ripgrep against the open-source Terminator SDK at github.com/mediar-ai/terminator. Each step carries a semantic record (what was clicked, what was typed, the target element, the parent window, the observed side effect) that a compliance reviewer can diff like any other code. Mediar is SOC 2 Type II certified and HIPAA compliant, with on-prem or cloud deployment.

What does Mediar cost compared with an enterprise RPA license?

Pricing is $0.75 per minute of runtime, with no per-seat licensing. There is a $10,000 turn-key program fee that converts to credits, so it functions as prepaid usage. For comparison, teams come to Mediar after a stalled UiPath or Power Automate project or a six-figure implementation quote; one F&B chain that moved from UiPath reported about 70% lower cost to their board.

How did this page land for you?

React to reveal totals

Comments ()

Leave a comment to see what others are saying.

Public and anonymous. No signup.