Skip to content

The API

A PDF generation API that returns the PDF

Publish a template, POST your JSON, and the response body is the document: application/pdf, in milliseconds, no job queue to poll and no signed URL to fetch afterwards. Async mode exists for batch work when you want it, not because the renderer needs it.

The whole integration

curl sync render 
curl -X POST 'https://api.pdfs.build/v2/organizations/org_abc/templates/invoice-primary/render' \
  -H 'Authorization: Bearer $API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"data": {"company": "Acme Corp", "items": [{"name": "Consulting", "qty": 3, "price": 150}]}}' \
  --output invoice.pdf

A contract, not a coin flip

Every template carries a JSON schema, and the API validates your payload against it before anything compiles. The failure modes are designed to be boring:

Bad payloads fail as JSON

A missing field or wrong type returns 400 with the validation details, never a corrupt file or a document with a blank where the total should be.

Deterministic output

Same template, same data, same PDF. Rendering is compiled typesetting, not a headless browser, so no upstream Chrome release ever shifts your layout. Why that matters.

Async when you want it

Add "async": true for background renders with a status URL and a render.completed webhook, or submit up to 500 documents as one batch. Sync stays the default.

Every render is logged

An audit trail answers "was this document ever generated, and with what data?" months later, filterable by template, status and date.

The template side of the API

Templates are managed over the same REST surface: create drafts, publish, unpublish, all addressed by an externalId you choose. Drafts are invisible to the render endpoint until published, so nothing half-finished can ever be rendered into a customer's inbox. How the templates themselves get designed is its own page: the short version is a gallery, an AI assistant, or importing the .docx you already have. Under the hood templates are Typst, and Typst users can bring their own.

There is also an MCP server, so an AI agent holding an API key can create and edit templates directly. If your stack already includes Claude or another MCP client, your agent designs the document and your backend renders it, over the same API. Details in the API reference and the MCP write-up.

Coming from another PDF API?

If you are currently rendering HTML through a headless-browser service or maintaining a LaTeX pipeline, the alternatives pages walk through the differences tool by tool, including what a migration actually involves and what you give up. The honest summary: if your document is a web page, keep the browser; if it is a business document generated from data, a template engine is the sturdier contract.

Render your first PDF in minutes

Free tier includes 2 templates and 50 watermarked PDF renders per month. No credit card required.

Get an API key