Most invoice PDFs are built twice: once as HTML for the web view, and again in a PDF library that lays out boxes by coordinate. The second one is where the effort goes and where the bugs live, because it has no layout engine - you are hand-placing text next to a total that moved.
Chromium already has a layout engine and a print stylesheet. Give it the HTML you have.
The request
curl -X POST https://api.ironfang.uk/renderwolf/v1/pdf \
-H "Authorization: Bearer if_live_..." \
-H "Content-Type: application/json" \
-d '{
"html": "<h1>Invoice INV-1042</h1>...",
"print_background": true,
"footer_html": "<div style=\"font-size:9px;width:100%;text-align:center;color:#666\">Page <span class=\"pageNumber\"></span> of <span class=\"totalPages\"></span></div>"
}' \
--output invoice-1042.pdfThe two settings that catch everyone
print_background: true keeps the colours. Browsers drop backgrounds when printing by default, which is sensible for a news article and wrong for an invoice with a coloured header - without it the PDF comes out looking broken rather than plain.
Inside those templates, Chrome's print classes work: pageNumber, totalPages, date, title, url. That is how you get real page numbers rather than a guess.
What it costs
A PDF is two credits rather than one, because it costs about twice as much to produce - the page is laid out, then paginated. Identical requests are served from cache and cost nothing, so re-fetching the same invoice is free.
