Commercial workflow page
Send a JSON payload from Python with requests or httpx, get back a filled PDF. No PyPDF2 / pypdf field-coordinate math, no reportlab redrawing, no LibreOffice headless. Free tier available.
Filling a PDF programmatically from Python sounds straightforward until production hits an unusual form. pypdf and PyPDF2 can update text fields but the API around radio groups, checkbox export values, appearance streams, and AcroForm flattening is awkward and frequently produces filled forms that look correct in some PDF viewers but blank or partially blank in others. fillpdf wraps pdftk, which is unmaintained and a heavy system dependency. reportlab generates PDFs from scratch but is not a fillable-form filler — you would be redrawing the document. The LibreOffice headless approach works but ships a 400MB binary and is painful to package on serverless.
The DullyPDF API replaces all of that with a single requests.post call. The PDF is detected and the field map is frozen at template publish time, so the JSON contract is stable across runs and across PDF readers.
A typical call from a Python 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 — pass `auth=(api_key, "")` to requests, or set the Authorization header manually as `Basic base64(api_key + ":")`. The response body is the raw PDF.
Most Python teams reaching for an external PDF fill API have a Flask, FastAPI, or Django backend with a record (a customer, an enrollment, a claim, a quote) that needs to be turned into a specific PDF — an ACORD certificate, a 1099 form, an HR onboarding packet, a state-specific government form, a generated invoice. They have already tried pypdf or fillpdf and ran into one of: forms that flatten incorrectly, radio groups that come back blank, output that looks fine in Preview but blank in Adobe Reader, or pdftk dependencies that broke on the first deploy.
In that shape, the API call is a one-line replacement. The JSON keys mirror the dictionary you would have built anyway. The output PDF is consistent across viewers because the fill engine and field detection are versioned with the saved template.
There is a place for in-process PDF libraries. pypdf is good for low-level inspection and trivial text-only field updates. reportlab is the right tool when you are generating a PDF from scratch and not filling an existing template. LibreOffice headless works for one-off conversions but is heavy. 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 across more than one Python service.
Because the API is a single HTTPS endpoint, every Python deployment shape works without extra setup. Long-running Flask, FastAPI, Django Channels, Celery batch workers, AWS Lambda with the slim runtime, Google Cloud Run, Heroku, Fly.io, and serverless Python runtimes all work because there is no system-level dependency to install. Cold starts stay fast because no PDF library has to load 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 in your Python service.
Need deeper technical details about pdf fill api for python? Use the Rename + Mapping docs and Search & Fill docs to validate exact behavior.
No. The API is plain HTTPS + JSON. requests, httpx, urllib, and aiohttp all work without any DullyPDF-specific package install.
For inspecting an existing PDF, pypdf is still the right tool. For filling a fillable PDF programmatically, the DullyPDF API is usually faster to integrate and produces output that renders consistently across PDF readers, including Adobe Reader.
Yes. Because the call is plain HTTPS with no native dependencies, every serverless Python runtime works. No need to bundle pdftk or LibreOffice.
Each published endpoint exposes a downloadable schema with the exact field names you reviewed during template setup. The schema is template-scoped and only changes when you intentionally republish.
Yes — call the same endpoint from httpx.AsyncClient or aiohttp. The endpoint is just an HTTPS POST and is async-runtime agnostic.
Use these docs pages to verify the exact DullyPDF behavior behind pdf fill api for python before you ship it as a repeat workflow.
These adjacent workflow pages cover nearby search intents teams compare while evaluating pdf fill api for python.
