Getting started with PDFops

30 seconds to a working PDF API call. No auth, no signup.

PDFops is live. Here's how to make your first call in three lines of shell.

Fill a PDF form

Pull a PDF with form fields off your desktop and swap in the field-name JSON.

curl -X POST https://pdfops.dev/api/fill-form \
  -F "pdf=@invoice-template.pdf" \
  -F 'fields={"customer_name":"Acme Co","total":"$1,250.00"}' \
  -o filled.pdf

You get a filled PDF back. The fields JSON keys match the AcroForm field names in your template (in the example above, an invoice template with customer_name and total fields).

Merge PDFs

Any number of pdf form parts. They're concatenated in the order you pass them.

curl -X POST https://pdfops.dev/api/merge \
  -F "pdf=@cover.pdf" \
  -F "pdf=@body.pdf" \
  -F "pdf=@appendix.pdf" \
  -o combined.pdf

Limits

100 requests per IP per month during beta. No signup, no auth. Hit the cap and you'll get a 429 Too Many Requests response with a Retry-After header set to the seconds until the next calendar month rolls (UTC).

If 100/mo is going to be the wrong number for you, join the waitlist — keys with 1,000–10,000/mo are coming, free during beta, and the form is how I'm prioritizing which endpoints ship next.

What's coming

The two endpoints above are what's live today. Next on the list:

• /api/stamp — apply text or image stamps to a PDF (think: confidential watermarks, page numbers, draft markers)
• /api/sign — sign a PDF programmatically
• /api/extract-text — pull text out of a PDF for downstream processing
• /api/redact — remove sensitive content destructively

Vote on the waitlist form for which one matters most for your use case. The waitlist is the only thing prioritizing what ships next.

Why this exists

The longer story is in Why I built PDFops — short version: every SaaS I've shipped eventually needs PDFs, the existing options either cost too much at scale or assume a backend stack I don't use, and I got tired of solving it from scratch every time.

← All posts · PDFops home