Skip to main content

Welcome to Paperwright

Paperwright is a collaborative PDF template designer. Design a document once — visually, with your team — then render it to a pixel-perfect PDF thousands of times, each filled with different data.

Think of it as the missing layer between a spreadsheet of data and a finished document: invoices, contracts, certificates, shipping labels, reports. You build the template; Paperwright produces the documents.

:::tip In one sentence A visual designer for anyone, backed by a render API for developers, with your whole team working on the same template at the same time. :::

Who we are​

Paperwright started from a simple, repeated frustration: generating PDFs is either too manual or too painful to automate.

The manual path is a designer hand-editing a Word or Figma file for every customer. The automated path is an engineer wrestling with a low-level PDF library — hard-coding coordinates, fighting fonts, redeploying to move a logo 2mm. Neither scales. Both put a wall between the people who know what the document should say and the people who can make the computer produce it.

We built Paperwright to remove that wall. The same template is editable by a non-technical teammate in a browser and callable by an engineer over an HTTP API. One source of truth, two audiences, zero copy-paste between them.

The problem → the solution​

The problemHow Paperwright solves it
Documents live in code. Moving a field means a PR, a review, and a deploy.A visual designer with drag-and-drop elements, smart alignment, and live preview. Non-engineers change the document directly.
Data and layout are tangled. The template hard-codes one customer's values.Templates are data-driven. You define a schema (invoiceNumber, total, lineItems[]), drop {{tokens}} onto the canvas, and pass JSON at render time.
"Design over our existing PDF" is impossible. Most tools only build from scratch.Base-PDF overlay. Upload an existing PDF and position elements right on top of it — WYSIWYG between designer and output.
Generating PDFs at scale is a chore. Every team rebuilds a renderer.A render API that turns template + data into a PDF in one call. ~9.5 renders/sec sustained on a single box, p95 ~1.1s.
Teams step on each other. Who changed the footer? Which version is live?Real-time collaboration — presence, comments with @mentions, and a save guard that refuses to silently overwrite a teammate's edit.
Building a template from a blank canvas is slow.AI template generation (beta). Drop a reference image and/or a description; get an editable draft in seconds.

Built for everyone​

Paperwright is deliberately a two-audience product. The same template serves both.

For non-technical users — the platform​

No code, no API keys. You work entirely in the browser:

  • A drag-and-drop designer with 18 element types — headings, tables, lists, images, QR/barcodes, charts, signatures, watermarks.
  • A schema panel to declare the data your document expects, with typed sample inputs and JSON import.
  • One-click preview to see your template filled with sample data.
  • Invite teammates, leave comments, and see who's editing — live.

→ Start here: For Teams

For developers — the API (and SDK, soon)​

Everything in the platform is backed by a clean HTTP API. Authenticate, manage templates, and render documents programmatically:

  • JWT for human/admin sessions (sign-up, login, managing keys).
  • API keys (X-Api-Key) for machine-to-machine rendering from your backend.
  • A /api/render inline endpoint for one-off renders, and /api/templates/{id}/render to render a stored template with fresh data.
  • A first-party .NET SDK is on the roadmap (Paperwright.Sdk) so a render is a single typed call.

→ Start here: For Developers · API Reference

:::info Two-lane auth, by design Humans authenticate with JWTs; machines authenticate with API keys. The render endpoints are the only ones that accept both — so your backend can render without ever holding a user's password, and a user can preview without minting a key. :::

Real-time collaboration​

A template is rarely one person's work. Paperwright treats collaboration as a first-class feature, not an afterthought:

  • Workspaces & roles — every template lives in a workspace; members are Owners, Editors, or Viewers. Everything is workspace-scoped, so tenants never see each other's data.
  • Invites — invite by email, share a link, accept into the workspace.
  • Presence — see "Sarah is viewing this template" live, via lightweight heartbeats. No one edits in the dark.
  • Comments & @mentions — discuss a template inline; mention a teammate to pull them in. Authors (or Owners) can resolve threads.
  • Safe concurrent saves — an optimistic-concurrency guard returns a conflict instead of silently clobbering a change made while you were editing.

Deeper real-time co-editing (CRDT-backed, à la multiplayer cursors) is on the roadmap; today's tier already keeps a team from stepping on each other.

How it fits together​

 ┌──────────────────┐     design      ┌─────────────────────┐
 │  Non-tech user   │ ──────────────▶ │                     │
 │   (browser)      │                 │     Paperwright      │
 └──────────────────┘                 │   template + schema  │
                                      │   (one source of     │
 ┌──────────────────┐    render API   │    truth)            │
 │  Your backend    │ ◀─────────────▶ │                     │
 │  (X-Api-Key)     │   PDF out       └─────────────────────┘
 └──────────────────┘

A designer builds the template; your code feeds it data and gets PDFs back. Both sides touch the same template.

Where to go next​

:::note Status Paperwright is pre-launch. The API documented here is v1. Endpoints are labelled Stable, Beta, or Experimental in the API Reference so you know what's safe to build on today. :::