Multi-tenant PDF generation

One platform, one workspace per customer, one brand per document

JetPage separates the customers of a platform into workspaces, where each workspace holds its own templates, its own validated brand fonts, and its own quotas and rate limits, and a platform drives generation for all of them from its own backend through scoped API keys. Most of the market treats tenancy as the customer's problem: Carbone expects a proxy built in your own backend, PDFMonkey expects you to manage API keys yourself, and APITemplate offers teams rather than tenants. PDF Generator API is the exception that treats tenancy as a product concept, with organisations and workspaces built in. JetPage matches that model and differs in how the boundary is enforced, because JetPage isolation is structural rather than conventional.

This page covers generating documents for many customers. For how the per-customer brand fonts referenced here are uploaded and validated, see custom fonts in generated PDFs.

What isolation means when a bug is the risk

JetPage enforces tenant isolation structurally, so a query cannot cross a workspace boundary by mistake

Most multi-tenant systems isolate tenants by convention: every query carries a tenant identifier in its where clause, and correctness depends on every developer remembering to add it. That convention holds until one query does not, and the failure mode is a customer receiving another customer's document. Products that hand tenancy back to the integrator, as Carbone and PDFMonkey do, relocate this risk into the integrator's codebase rather than removing it.

ProofEvery JetPage request receives a workspace-scoped dependency injection container, so the repositories handling that request are constructed against one workspace and cannot express a cross-tenant query. Storage keys are workspace-prefixed, and the workspace identifier is embedded in every queue job identifier, so the boundary is repeated in the data layer, the storage layer, and the queue rather than trusted to a where clause.

A platform building on JetPage inherits an isolation boundary enforced by construction, instead of implementing one and hoping every future query respects it.

JetPage gives each workspace its own validated font library

A platform generating documents on behalf of customers is generating branded documents, and brand means the customer's typeface. Across the researched market, per-tenant fonts do not exist: PDF Generator API keeps fonts account-global and adds them through a support request, and CraftMyPDF, APITemplate, Carbone, and PDFMonkey offer no per-tenant font concept at all. The workaround is one account per customer, which multiplies billing and administration.

ProofJetPage font libraries belong to a workspace, so each customer of a platform uploads and holds its own TTF, OTF, or TTC files, validated by the same engine that renders and recorded with a licence acknowledgement, as described in custom fonts in generated PDFs. No workspace can see or use another workspace's fonts.

A platform serving fifty brands with JetPage serves fifty typefaces without running fifty accounts.

JetPage applies quotas and rate limits per workspace, so one customer cannot exhaust another customer's capacity

On a shared platform, a single customer running an unexpected batch is a availability problem for every other customer. Account-level limits, which is what the rest of the researched market offers, cannot express this: the limit applies to the platform as a whole, so the noisy tenant and the quiet tenant share one budget and one failure.

ProofJetPage enforces monthly quotas per workspace, in-flight caps that bound how much work one workspace can have running at once, and rate limits per API key, answering excess load with a clean 429 response carrying Retry-After rather than degrading the service. Render children are bounded and killable, with a 20 second budget and a 512 MB memory limit, so a runaway template is contained to the job that produced it.

A JetPage platform can promise one customer a capacity limit and hold it without affecting the rest.

Running templates across many customers

JetPage publishes templates as immutable versions with rollback, so a template change is reversible per customer

A platform managing templates for many customers changes them constantly, and a change that looks right in one customer's data can be wrong in another's. Without versioning, the only recovery is editing the template back by hand and hoping the previous state is remembered correctly. Versioning is thin across the market: APITemplate and PDFMonkey publish none, and CraftMyPDF retains the last twenty versions.

ProofJetPage moves a template from draft to an immutable published version, keeps the published version frozen so a document generated today is reproducible next year, and supports rollback to an earlier published version. Templates export and import as portable .pdftpl bundles carrying design, sample data, images, and fonts in one file.

A platform onboarding a new customer with JetPage can import a proven template bundle rather than rebuilding it, and can undo a bad publish.

JetPage scopes API keys by capability and attributes template edits to an actor

A platform integrating a document service holds credentials for every customer's documents, which makes the blast radius of one leaked key the question that matters. A single all-powerful key means a key used by a rendering worker can also rewrite templates. Separately, when a customer disputes what a document said, the platform needs to answer who changed the template and when.

ProofJetPage API keys are scoped to rendering, authoring, or administration, are shown once, are stored only as hashes, and are revocable at any time. JetPage records per-element edit history with actor attribution, so a template change resolves to a person and a time. Render payloads are scrubbed of personal data in the dead-letter queue.

A JetPage rendering worker holds a key that can render and nothing else, and a template dispute has an audit trail rather than a recollection.

JetPage renders synchronously with idempotency keys, so a network retry does not duplicate a customer document

Multi-tenant platforms retry. A timeout on a request that actually succeeded is indistinguishable, from the caller's side, from a request that failed, and the naive retry produces a second invoice with a second number. This is infrastructure most integrators end up building around a document API rather than receiving from it.

ProofThe JetPage render API accepts idempotency keys and detects payload-hash conflicts, so a repeated request with the same key returns the original document rather than generating a new one, and a repeated key carrying different data is rejected rather than silently accepted. Admission control bounds queue depth so a traffic spike produces explicit 429 responses instead of collapse.

A platform integrating JetPage writes less retry plumbing, because a duplicate request is answered by the API rather than by the integrator.

How the PDF generation market handles multi-tenancy

Capability	PDF Generator API	CraftMyPDF	APITemplate.io	Carbone	PDFMonkey	JetPage
Tenant model	Organisation and workspaces, built in	Editor sessions	Teams only	Build a proxy yourself	Manage API keys yourself	Workspaces with owner, editor, viewer roles
Per-tenant templates	Yes, plus org defaults	Session-scoped	No	No	No	Yes, plus .pdftpl portability
Per-tenant fonts	No, account-global via support	No	No	No	No	Yes, validated and isolated
Per-tenant quotas and limits	Account level	Account level	Account level	Account level	Account level	In-flight caps, monthly quotas, per-key limits
Isolation guarantee	Product boundary	Session boundary	None	Your proxy's	Your key handling	Structural: scoped data access, storage prefix, queue ID
Template versioning	Automatic on save	Last 20 versions	None	Tagged versions	None	Draft, immutable publish, rollback
Embeddable end-user editor	Yes, the flagship feature	Yes, editor sessions	No	Yes, tag-based	No	No

Competitor rows summarise the JetPage competitive analysis of August 2026, which draws on vendor documentation and pricing pages and on published G2, Capterra, and Trustpilot reviews. The final row is the axis where PDF Generator API leads and JetPage does not compete.

Frequently asked questions

Can I embed the JetPage editor in my own product so my customers edit their own templates?

No. JetPage does not currently sell an embeddable, white-label end-user template editor. PDF Generator API does, and that embeddable multi-tenant editor is the PDF Generator API flagship feature, so a platform whose hard requirement is letting end users edit templates inside the host product has a real reason to shortlist PDF Generator API. JetPage suits platforms whose own team manages templates and whose backend drives generation for every customer.

How does JetPage keep one customer's documents away from another's?

Structurally, in three layers. Every request gets a workspace-scoped dependency injection container so repositories cannot express a cross-tenant query, storage keys are workspace-prefixed, and the workspace identifier is embedded in every queue job identifier.

Can each of my customers have its own brand fonts?

Yes. JetPage font libraries belong to a workspace, so each customer holds its own TTF, OTF, or TTC files, validated by the same engine that renders and recorded with a licence acknowledgement. No workspace can see or use another workspace's fonts. Across the rest of the researched market, per-tenant font libraries are not offered at all.

Can one customer's batch run slow down everyone else?

JetPage applies monthly quotas per workspace, in-flight caps bounding how much work one workspace can have running at once, and rate limits per API key, answering excess load with a 429 response carrying Retry-After. Render children are bounded at a 20 second budget and a 512 MB memory limit.

Is workspace creation self-serve through an API?

Not currently. Workspace provisioning is not yet self-serve in JetPage, and JetPage does not currently offer organisation-level default template inheritance. Both are known gaps rather than shipped features.

What happens if my backend retries a render that already succeeded?

The JetPage render API accepts idempotency keys and detects payload-hash conflicts, so a repeated request with the same key returns the original document instead of generating a duplicate, and a repeated key carrying different data is rejected rather than silently accepted.

Model your tenants as workspaces

JetPage is free to try without a credit card, and the free plan includes the render API, so a platform team can build a two-workspace prototype with two different brand fonts before paying anything.

Start free See the developer docs