---
title: "Wedding Invitation API: One Design, Every Guest"
description: "A wedding invitation API renders a personalized card per guest: names that resize to fit, an RSVP QR code, and a print-ready PDF from the same design."
url: "https://www.imejis.io/blogs/use-cases/wedding-invitation-api"
published: "2026-09-25"
---

# Wedding Invitation API: One Design, Every Guest

A wedding invitation API renders one personalized card per guest from a single design. The guest's name, their table, a QR code pointing at their own RSVP link: all of it varies per render, and the layout doesn't move.

That's the difference between this and a mail merge into a document. The card is a designed, fixed canvas, so guest 4 and guest 194 get typography that lands identically. Nothing reflows because somebody has a long surname.

Want to see one first? The [wedding invite maker](/tools/wedding-invite-maker) is free, needs no signup, and adds no watermark. This post is for the list.

## Names are the thing that breaks invitations

Guest lists are where a layout meets reality. "Jo" and "Dr. Aleksandra Konstantinopoulou" are both going on the same card, in the same slot, at the same position.

Pick a font size for the short one and the long one overflows. Size it for the long one instead and the short one sits marooned in white space. The usual manual fix is checking all 200 by eye, which is exactly the job you were automating away.

Auto-resize solves it in the design. Set `minFontSize` and `maxFontSize` on the name layer and the renderer shrinks the type until the string fits its box:

```json
{
  "key": "guest_name",
  "type": "text",
  "dynamic": true,
  "properties": {
    "text": "Aleksandra Konstantinopoulou",
    "minFontSize": 22,
    "maxFontSize": 48,
    "textAlignment": "center"
  }
}
```

Set the minimum where the card still reads well rather than as low as it can go. A name at 12pt technically fits and nobody will thank you for it. [Text on image](/blogs/tutorials/text-on-image-api) has the fuller version of this behaviour.

## A QR code per guest, not per wedding

One QR pointing at a shared RSVP page works. A QR carrying the guest's own token is better, because the person scanning it doesn't have to find their name in a list.

Mark the QR component's value dynamic and pass a per-guest URL:

```bash
curl -X POST 'https://render.imejis.io/v1/YOUR_DESIGN_ID?format=pdf' \
  -H 'dma-api-key: YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "guest_name": { "text": "Aleksandra Konstantinopoulou" },
    "table":      { "text": "Table 7" },
    "rsvp":       { "value": "https://rsvp.example.com/g/8fc21a" }
  }' \
  --output guest-8fc21a.pdf
```

QR codes carry error correction, so a modest amount of damage or a printed finish still scans. The [ISO specification](ref:iso/standard/62021.html) is the reference if you want the detail. Practically: print one, scan it with an actual phone in the actual lighting, before you print two hundred.

One caution worth stating. QR renders through the API; **barcode does not**. The barcode component works in the editor and the free tool is client-side, so if your plan involves scannable barcodes on printed cards, that path stops here.

## Print comes out of the same design

Ask for `pdf` and the render returns a single-page PDF at the canvas size. Three things follow from that:

- **Design at the finished card size.** Dimensions are fixed when you build the design, so a 5 by 7 inch card is a 5 by 7 inch design. There's no resize at render time.
- **Renders cap at 4096 by 4096.** A 5 by 7 card at 300 DPI is 1500 by 2100, so print resolution is not a constraint here.
- **One page per render.** A card is one page, which fits. An order of service booklet is not, and that belongs with a document engine.

Fonts embed from the design, so the printer's machine doesn't need your script face installed.

## What a wedding invitation API costs

One render per guest, per attempt.

| Guest list                        | Cards  | Renders | Plan              |
| --------------------------------- | ------ | ------- | ----------------- |
| 60, invitation only               | 1 each | 60      | Free, 100 a month |
| 200, invitation only              | 1 each | 200     | Basic, $14.99     |
| 200, plus a place card and a menu | 3 each | 600     | Basic, $14.99     |

As of September 2026 the free allowance is 100 renders a month, free, forever. The number that catches people is the re-run: fixing one misspelled name and re-rendering the batch costs another full pass. Proof the list first, then render. The [pricing page](/pricing) has the plan detail.

## Honest scope

This generates the cards. It doesn't address envelopes, doesn't post anything, and doesn't run your RSVP tracking, though the QR can point at whatever does. For a single wedding, we'd tell you to use the free tool and spend the afternoon on something else. The API earns its place when you're a stationer or a venue doing this every week for different clients, where one design serves every event and only the data changes.

## Getting started

Lay the card out in the [invite maker](/tools/wedding-invite-maker) first, then rebuild it as a design, add a [QR component](/components/qr) for the RSVP, and mark the name, table and QR value dynamic. [Dynamic fields](/help/dynamic-fields) covers what to open up, and the [API docs](/apis) have loop-ready examples in Node, Python and PHP.