A PDF from the API, without a browser

GET /api/v1/documents/:id.pdf lays a document out as a PDF on the server, for a script or a CI job that has no browser to print from. The app itself still uses "Print or save as PDF" for that — it is the browser's own, exact rendering, and this does not replace it.

GET /api/v1/documents/:id.pdf, with an API key, returns a laid-out PDF of a saved document. It is meant for the case that has no browser in it: a scheduled job, a CI step that attaches a report to a release, a script that mails a weekly summary.

Why this exists separately from printing

Most Markdown-to-PDF tools are a headless Chrome in a trench coat. That gives an exact rendering and costs a browser: several hundred megabytes of dependency, a sandbox to keep it in, a start-up per request, and a memory ceiling that a long document reaches before a person does. None of that fits inside a serverless function, and a service that quietly starts a browser per request is a service that is slow and expensive for the one case that could have been neither.

This lays the document out directly — headings, paragraphs, lists, tables, code blocks and rules — with no browser anywhere in the path. It starts immediately and finishes in milliseconds.

What it is not

It is not a pixel-for-pixel copy of the preview. The app's own Print or save as PDF still uses the browser's own rendering, which is exact, and that has not changed: if you want the page as you see it, print it. If you want a PDF from a machine, ask for one.

Using it

curl -H "Authorization: Bearer tp_live_…" \
  https://transformpipe.com/api/v1/documents/<id>.pdf -o report.pdf

The same document is available as .docx, .html and .md by changing the extension, so one saved document is four formats without a second conversion.

Related: the ways Markdown becomes a PDF, and converting documents with an API.