PDFops v0.11: ten new PDF operations, in the API and in every client

v0.10 in August was the no-code on-ramps release. v0.11 is the operations release. The API had three PDF primitives, inspect, fill and merge, plus an invoice renderer. It now has fourteen PDF endpoints, and every client we ship, the n8n node, the MCP server, the TypeScript SDK and the Python package, carries the same set at the same version of the contract.

Ten new endpoints

Each one takes the multipart shape /api/fill-form already uses: a pdf file, a few string fields, and a PDF back. The limits are the same too, 4 MB and 2,000 pages per input PDF, and every call counts against the same quota as a fill or a merge.

Splitting a packet into two-page parts, from a shell:

curl -X POST https://pdfops.dev/api/split \
  -F "[email protected]" \
  -F "every=2" \
  -o parts.json

fill-form resolves field names forgivingly

An exact field name still wins, every time. When no field has the exact name you sent, the key and each field name are compared in a normalized form: Unicode-normalized, lowercased, with only letters and digits kept and array indices like [0] removed, against the full name and against its last dotted segment. The field's label, the tooltip a form author typed in Acrobat, is compared the same way. So F1 01 fills f1_01, and First Name fills the field whose tooltip says that, whatever its internal name is.

Only a unique match resolves. A key that matches two fields is a 422 that lists up to five candidates, and a key that matches none lists up to three similar names. The endpoint still refuses to skip unknown keys silently, because that is how wiring bugs reach a signed document. The full rules are under Field matching.

Encrypted templates open on their own

Most government blanks are owner-locked with an empty user password: anyone can open them, and only edits are restricted. Until October, every one of them came back as encrypted_pdf with a pointer to qpdf. Now fill-form, inspect, merge and all ten new endpoints open those files themselves. A PDF with a real user password takes it in the password form field, and unlock is there when you want the file re-saved without encryption for good.

The same operations in every client

The point of a small API is that each wrapper can carry all of it. As of this week, all four do:

from pdfops import PdfOps

client = PdfOps()  # reads PDFOPS_API_KEY from the environment

result = client.split("packet.pdf", every=2)
for i, part in enumerate(result.parts):
    stamped = client.watermark(part.pdf, "COPY", opacity=0.2)
    open(f"part-{i + 1}.pdf", "wb").write(stamped)

print(client.metadata("packet.pdf")["page_count"])

Fixed: a long multiline value could stall a fill

A multiline text field given tens of kilobytes of text with no line breaks could run past the edge function's time limit and come back as a 504. The cause was in the layout step underneath: for one unbroken paragraph, pdf-lib's line breaking does work that grows with the cube of the word count, so a value that filled a page in a viewer took minutes to lay out on a server. Since 2026-11-08, fill-form wraps any line over 300 characters that is wider than its field before the layout runs. The stored value gains newlines at those points; shorter lines, and lines that fit, are stored exactly as sent. The 60 KB value that timed out now returns in about two seconds.

Also since v0.10

Try it

Watermark a draft, with no signup. The keyless trial allows 100 calls per IP a month:

curl -X POST https://pdfops.dev/api/watermark \
  -F "[email protected]" \
  -F "text=DRAFT" \
  -F "opacity=0.2" \
  -o draft.pdf

A free key from /docs/signup raises that to 250 calls a month, no card. Every endpoint has a reference page under /docs and a schema in openapi.json. A workflow these fourteen endpoints still do not cover is the most useful thing you can tell us.