DEV Community: Rahul

I made an invoice PDF API that doesn't need a headless browser

Rahul — Mon, 27 Jul 2026 06:17:32 +0000

Generating a PDF shouldn't require a headless browser

Every time I needed to generate an invoice or receipt PDF, the options were:
wrestle a low-level PDF library, fight a templating engine, or spin up headless
Chromium (slow, heavy, breaks on fonts, painful to host). For a document, that
felt absurd.

So I built InvoicePDF: POST JSON, get a clean invoice PDF back.
That's the whole thing.

curl -X POST https://invoicepdf-app.azurewebsites.net/invoice \
  -H "Content-Type: application/json" \
  -d '{
    "number": "INV-2026-001",
    "currency": "USD",
    "seller_name": "Your Company LLC",
    "buyer_name": "Acme Corp",
    "items": [
      { "description": "Consulting (hours)", "quantity": 8, "unit_price": 120 },
      { "description": "Software license", "quantity": 1, "unit_price": 299 }
    ],
    "tax_rate_percent": 10,
    "notes": "Thank you!"
  }' --output invoice.pdf

Why pure Python (no chromium)

It's built on fpdf2 — a pure-Python PDF library — so there's no headless
browser and no system dependencies. That means it starts instantly, uses
almost no memory, and deploys on a free tier like a static app. For structured
documents (invoices, receipts, statements), you don't need a browser; you need
correct layout and correct math.

The money math is exact

Financial documents can't have floating-point drift. InvoicePDF does all money
as integer minor units (cents/paise) internally, so $27.00 subtotal + 10% tax is exactly $29.70 — never $29.700000001. It handles multiple currencies
(including zero-decimal ones like JPY), fractional quantities (e.g. hours), tax,
notes, and due dates.

Try it / use it

Live playground (edit JSON, get a PDF): https://invoicepdf-app.azurewebsites.net
Sample PDF: https://invoicepdf-app.azurewebsites.net/sample
Open source (MIT): https://github.com/rahulatrkm/invoicepdf

Free tier is 100 invoices/mo, no signup. If you generate a lot, there's a cheap
paid tier.

What would make this actually useful in your stack — logo/branding, a hosted
template editor, webhooks? Genuinely curious — feedback welcome.

The robots.txt mistake that hides your whole site from Google

Rahul — Mon, 27 Jul 2026 05:11:05 +0000

One line can hide your whole site from Google

Disallow: / in your robots.txt tells every crawler to ignore your entire
site. It's shockingly common — usually left over from a staging config that got
copied to production. And nothing tells you: your pages just quietly stop
ranking.

I kept getting bitten by robots.txt and sitemap.xml issues, so I added free
checks for them to OGCheck.

Check your robots.txt in one request

curl "https://ogcheck-app.azurewebsites.net/robots?url=https://your-site.com"

It confirms the file is reachable, parseable, flags a site-wide block,
and tells you whether it points at your sitemap.

The robots.txt mistakes that quietly cost you traffic

Disallow: / — blocks everything. The classic staging-to-prod accident.
Missing file — crawlers assume everything is allowed, which may expose pages you didn't mean to (and you lose the chance to point at your sitemap).
No Sitemap: line — search engines crawl your site less efficiently.
Blocking your CSS/JS — Google renders pages; blocking assets can hurt how it sees them.

While you're at it, check your sitemap too

A broken or empty sitemap.xml hurts crawl efficiency the same quiet way:

curl "https://ogcheck-app.azurewebsites.net/sitemap?url=https://your-site.com"

Both checks are free, zero-dependency (pure Python stdlib), and open source:
https://github.com/rahulatrkm/ogcheck. There's also a social-preview check
(/check?url=…) that confirms your og:image actually loads.

Feedback welcome — what else silently breaks your site's visibility that a
one-request check could catch?

Your blog's link preview is probably broken — here's a 1-line CI check

Rahul — Mon, 27 Jul 2026 04:54:24 +0000

The silent bug that quietly kills your click-through

You add <meta property="og:image" content="...">, the preview looks fine when
you test it, you ship. Weeks later the image gets moved, the CDN path changes, or
it was a relative URL all along — and now every share is a blank card. Your
click-through quietly drops and nothing alerts you.

Catch it in one request (or in CI)

I built OGCheck to catch exactly this. It parses your Open Graph +
Twitter Card tags, scores them, and — the key part most validators skip —
actually requests the og:image to confirm it returns HTTP 200.

python -m ogcheck https://your-site.com/blog/post
# exits non-zero if og:image 404s or required tags are missing -> perfect for CI

There's a JSON API and a GitHub Action too:

- uses: rahulatrkm/ogcheck@v1
  with:
    url: https://your-site.com

The 5 things that actually break previews

The image URL 404s (most common)
A relative URL instead of an absolute one
A cached old preview on the platform (re-scrape to bust it)
Wrong dimensions or file type (use PNG/JPG at 1200×630)
Crawlers blocked by robots.txt or auth

It's a small "site health" suite now

Same free API also checks the other things that silently break how your site
shows up:

GET /check?url=… — social preview (Open Graph + og:image loads)
GET /robots?url=… — robots.txt (catches an accidental site-wide Disallow: /)
GET /sitemap?url=… — sitemap.xml (valid XML, reachable, lists URLs)

It's free, zero-dependency (pure Python stdlib), and open source:
https://github.com/rahulatrkm/ogcheck

If you monitor a lot of pages, I'm thinking about a paid "watch these URLs and
alert me when a preview breaks" tier — would that be useful? Honest feedback
very welcome, especially on false positives.