PDF documents

Sites can generate PDF documents — invoices, receipts, tickets, certificates, contracts, packing slips — from templates you author alongside the rest of the site. A document is produced from your own logic, in a handler or a scheduled task, at the moment there's something to produce it for.

Document templates

Documents are templates like any other part of the site: the same templating language, the same layouts and partials, with the data supplied by the code that generates them. They aren't pages and have no URL of their own — nothing routes to them; they exist to be rendered on demand.

Unlike email, the site's own Tailwind styling and theme apply, so a document is styled exactly the way the site is and picks up brand changes automatically. Print utilities let you control where pages break — keeping a table row or an invoice total from splitting across a page boundary.

The page box

Each template declares its own paper: size (A4, Letter, Legal, or explicit dimensions), orientation, margins, and whether background colors print. It also declares the document title and the filename the recipient sees, both of which can include the document's data — invoice-1043.pdf rather than something generic.

A header and footer band can run on every page, and it's the one place page numbers can appear ("Page 2 of 5"), since a repeating running head isn't something the page body can express.

Documents render without client-side JavaScript, so everything that should appear must come from the template itself rather than from a script that runs afterwards. Where a document needs a scannable code — a ticket, a scan-to-pay line on an invoice — a qr_code filter generates one inline.

Localized documents

Document templates join the same translation pipeline as the rest of the site, and you choose the language when you generate. An invoice can be produced in the customer's language without maintaining a separate template per locale.

What you do with the result

Generating a document hands you back a reference to the finished file rather than the bytes, and there are three things you'd normally do with it:

• Store it against a record — attach it to the order, booking, or account it belongs to, so it becomes a permanent part of that record in the database.
• Serve it as a download — return the file from a handler, which means your own access checks apply. An invoice stays behind login instead of sitting at a guessable public URL.
• Attach it to an email — send the receipt or ticket with the message that announces it.

Generate once, reuse

The intended pattern is to generate a document once, at the point the underlying thing happens, store it, and serve the stored file from then on. A customer downloading their invoice for the third time should get the file you already made, not a fresh render — it's faster for them, and it's what keeps a busy site well inside its allowance.

It also means the document is a record of what was true when it was issued. Regenerating an old invoice from today's data can quietly produce a different document than the one the customer received.

Limits

• Per run — a single handler or task run can generate a small number of documents, so one request can't run long enough to time out. Larger jobs — a month-end batch of statements — belong in a scheduled task that works through them across runs.
• Per document — a document has a maximum page count, which is generous for real documents and only reached by an unbounded loop over a table.
• Per day — each site has a daily document allowance set by its plan.

Generation reports failure rather than raising an error, so your logic decides what happens next: retry later, skip, or carry on without the document. The report distinguishes a temporary problem from a permanent one and from simply having reached a limit.

PDF generation is part of the higher plan tiers; agency-owned sites include it. See Capabilities overview.