Generating a PDF from HTML you wrote is a different job from archiving someone else's page, and the settings differ.
curl -o invoice-8891.pdf \
"https://api.screenshotline.com/take?url=https://example.com/invoices/8891&format=pdf&full_page=true" \
-H "X-Access-Key: $KEY"
When the HTML is yours
Write a print stylesheet. You control the markup, so use @media print to
hide navigation, expand collapsed sections and set sensible margins. That
single change does more than any renderer option.
Pick a width deliberately. The capture uses the viewport width you ask for, so a document rendered at 1280 is a wide page. For something that will be printed, render at a width that matches the paper you expect.
Use full_page=true for one continuous document, which is usually right
for invoices and reports that are read on screen.
Protect the URL. An invoice URL that renders for anyone who guesses the
number is a data leak with a PDF attached. Use a signed URL, a token in the
path, or render from a server-side route that checks the session and passes
headers or cookies through to the renderer.
Passing authentication
If the page needs a session, send it:
&cookies=session%3Dabc123
&headers=Authorization%3ABearer%20token
Those are part of the cache key, so an authenticated render never collides with the anonymous one.
Fonts and emoji
The renderer ships CJK and colour emoji fonts, so a document with a customer name in Japanese or a status emoji in a table does not come out as boxes. That is worth checking in whatever you use, because it is the most common silent defect in HTML-to-PDF pipelines.
What this is not
It is not a typesetting engine. If you need precise pagination, running headers, page numbers and a table of contents, you want a library built for documents rather than a browser screenshotting a page.