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 is free, needs no signup, and adds no watermark. This post is for the list.

Names are the thing that breaks invitationsNames 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:

{
  "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 has the fuller version of this behaviour.

A qr code per guest not per weddingA 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:

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 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.

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 costsWhat a wedding invitation API costs

One render per guest, per attempt.

Guest listCardsRendersPlan
60, invitation only1 each60Free, 100 a month
200, invitation only1 each200Basic, $14.99
200, plus a place card and a menu3 each600Basic, $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 has the plan detail.

Honest scopeHonest 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 startedGetting started

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

Frequently asked questions

Design the invitation once with the guest name marked dynamic, then loop your guest list and render one card per row. Each render returns a finished file, so a 200-name list becomes 200 invitations in one script run.

Set minFontSize and maxFontSize on the name layer and the type shrinks until it fits. That's what keeps 'Jo' and 'Dr. Aleksandra Konstantinopoulou' both sitting cleanly inside the same card without anyone checking each one.

Yes. Add a QR component and mark its value dynamic, then pass a per-guest URL containing that guest's token. Every card gets its own code, so the RSVP page knows who scanned it without them typing anything.

Ask for PDF as the format and the render comes back as a single-page PDF at the design's canvas size. Design at the finished card size, because dimensions are fixed at design time and can't be changed in the render call.

200 renders, one per invitation. As of September 2026 that's inside Basic at $14.99 for 1,000 renders a month, and a re-run after a spelling fix costs another 200, so proof the guest list before the first run.

We use cookies to run the site and, with your consent, for analytics and marketing. See our Cookie Policy. You can change this any time from “Cookie settings” in the footer.