Personalized Print API: The Shared Mechanics
A personalized print API turns a list of people into a stack of print-ready files. One design, one row of data per person, one file out. Certificates, wedding invitations, event badges, children's book covers and corporate holiday cards all look like different products and are the same four mechanics underneath.
Knowing the mechanics is what lets you build the second one in an afternoon instead of starting over. Here they are, and then which specific guide you actually want.
The four mechanics of a personalized print apiThe four mechanics of a personalized print API
1. The canvas is fixed, deliberately. Width and height are set when you build the design and can't be overridden per render. Print requires this. Every file in a run has to be one trim size or the printer sends the batch back, and a fixed canvas makes that true by construction rather than by checking.
2. Only marked properties change. A layer's properties are baked in unless you mark them dynamic. The name varies; the artwork, the logo and the brand colour can't be touched by a malformed row. Mark as little as the job needs.
3. Type has to absorb the variation. Names are the most variable data in any of these jobs. minFontSize and maxFontSize shrink the type until the string fits its box, so "Bo" and "Alessandra" both sit inside the same slot without anyone checking each file.
4. One render per file, every time. Including reprints, re-runs, and a render identical to one you already made. This is the whole cost model and it's the number people get wrong.
Everything below is those four applied to a specific job.
Which one do you actually needWhich one do you actually need
| Your job | The guide | The distinctive problem |
|---|---|---|
| Course completions, awards, diplomas | Certificate generator API | Single-page PDF, and where a document engine wins |
| One card per guest, with an RSVP code | Wedding invitation API | Per-guest QR codes and print sizing |
| A child's name inside cover artwork | Personalized book cover API | Custom fonts, glyph coverage, reprint margin |
| A client list in the thousands, on a deadline | Corporate holiday card API | Proofing the list before spending the renders |
| Several photos in one fixed layout | Photo collage API | Fitting arbitrary photos into fixed slots |
They share the mechanics and differ in the thing that bites, which is why each has its own guide rather than one post with the noun swapped.
The ceiling every one of them hitsThe ceiling every one of them hits
A render returns a single page. That's the boundary of this whole category, and it's worth knowing before you design a product around it.
A certificate is one page. An invitation is one page. A book cover is one page. A 24-page personalized picture book is not, and neither is a 12-page report with a personalized cover. Those are one render per page plus an assembly step you run yourself, which is a real workflow but a different one. If a bound multi-page document is the product, APITemplate has a proper document engine and we don't.
Renders also cap at 4096 by 4096, which covers A4 at 300 DPI (2480 by 3508) comfortably, with room for bleed.
The cost model in one sumThe cost model, in one sum
Multiply recipients by files per recipient, then add a re-run.
| Job | People | Files each | Renders | Plan |
|---|---|---|---|---|
| Course cohort | 400 | 1 certificate | 400 | Basic, $14.99 |
| Wedding | 200 | invite, place card, menu | 600 | Basic, $14.99 |
| Book orders | 900 | 1 cover | 900 | Basic, $14.99 |
| Client cards | 5,000 | print and email | 10,000 | Unlimited, $69.99 |
As of September 2026, Basic is 1,000 renders a month, Pro is 5,000 and Unlimited is 25,000. Below all of it sits 100 renders a month, free, forever, which is enough to build and test any of these properly before paying anything.
The line people miss is the re-run. One wrong name spotted after the batch means rendering the batch again at full price. Budget a spare run rather than exactly the number of recipients, and proof 20 rows before committing to the rest. Render quota covers how the counters work and when they reset.
The list is personal dataThe list is personal data
Worth saying plainly, because it's the part that gets skipped in a print pipeline.
A personalized print run means holding real people's names, often with addresses, sometimes with a child's name and birthday. Under the GDPR and its equivalents that's personal data, and running it through a render step doesn't change the obligations.
Two practical consequences specific to this workflow:
- Hosted delivery makes a public URL. A hosted render is a permanent, unguessable but public link to a file with somebody's name on it. For anything personal, prefer streaming the bytes to your own storage, or signed delivery with a lifetime that matches how the file is actually used. Signed URLs default to 60 minutes and cap at 7 days.
- Keep the list as long as the run, not longer. The export you cleaned in November has no reason to still be sitting in a bucket in March.
Neither is exotic. Both are easy to get wrong when the print deadline is the only thing anyone is thinking about.
Start with the smallest versionStart with the smallest version
Pick the single most common file you produce by hand today. Rebuild it as a design at its finished print size, mark only the fields that genuinely vary, and render twenty real rows. Look at the output, look at the warnings header, then decide whether the rest is worth automating.
The API docs have working calls in 33 languages, dynamic fields covers marking properties, and the free tools let you settle a layout before you build anything.