Turn an HTML page into a PDF via API

Invoices, receipts, reports and certificates. You already have the HTML and CSS — the job is turning a URL into a file a customer can keep.

The call

curl -X POST https://api.screenmint.dev/v1/screenshot \
  -H "X-API-Key: sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/invoices/inv_1042?token=one-time-token",
    "format": "pdf",
    "full_page": true,
    "width": 1240
  }'

full_page: true captures the whole document rather than one viewport, so a three-page invoice comes back as three pages.

The problem nobody warns you about

An invoice is behind a login. A renderer is a browser that is not logged in as your customer, so it will faithfully produce a PDF of your sign-in page — and because a PDF of a login screen is still a valid PDF, this tends to be discovered by a customer rather than by your tests.

Three ways out, in order of preference:

• A single-use signed token in the URL. Your app renders the invoice for that token once, then invalidates it. Nothing long-lived is exposed, and the renderer needs no session.
• A dedicated internal route that takes an id, checks a shared secret header, and renders the document without a user session.
• Never a real session cookie. It grants far more than one document, and it will end up in a log.

Do not put secrets in the URL

Renders are cached by their parameters, which is what makes repeats free — but it means a URL is a cache key. Use one-time tokens that expire, never a long-lived key, and treat any query string you send as something that will be stored.

Getting the layout right

Set an explicit width: 1240 approximates A4 at 150 DPI and gives predictable line breaks. Use @media print in your CSS to drop navigation and buttons, and page-break-inside: avoid on table rows so a row is never split across pages. Test with a long document early — pagination bugs only appear past the first page.