---
title: "Corporate Holiday Card API: 5,000 in One Run"
description: "A corporate holiday card API renders one card per client from your list. How to proof 5,000 rows before spending 5,000 renders, and the print and email split."
url: "https://www.imejis.io/blogs/use-cases/corporate-holiday-card-api"
published: "2026-10-10"
---

# Corporate Holiday Card API: 5,000 in One Run

A corporate holiday card API renders one card per client from a list you already have. Name, company, the account manager who signs it: all of it varies per render, and the card doesn't move.

The design is the easy half and it's where most of the panic goes. The half that decides whether the run succeeds is the list, because a 5,000-row job fails in exactly one way: it renders 5,000 perfect cards with something wrong in them, and you find out after they're printed.

## The deadline is the constraint

A holiday card has a date it stops being useful, and print has a lead time in front of that date. So the schedule works backwards, and the render step is the smallest piece of it.

| Step                  | Owns the risk | Time                                |
| --------------------- | ------------- | ----------------------------------- |
| List export and clean | You           | Days, and always more than expected |
| Design and sign-off   | You           | Days                                |
| Proof run, 20 rows    | The render    | Minutes                             |
| Full render, 5,000    | The render    | Minutes                             |
| Print and mail        | Printer       | Weeks                               |

Rendering is the cheap, fast, repeatable step. Getting the list right is neither, which is why the rest of this is mostly about the list.

## Proof the list before you spend the renders

Every render costs a render, including one you're throwing away, and a re-run after a data fix costs the full batch over again. So the proof step earns its time.

Render the first 20 rows and check three things.

**The warnings header.** When you send an override key that matches no dynamic layer, the render still succeeds and the header `x-dma-warnings` says so. That's the typo case: send `client_name` when the layer key is `clientName` and you get 5,000 cards with an empty name and no error anywhere. Read the header on the proof run and the whole class of problem disappears:

```bash
curl -sS -D headers.txt -X POST 'https://render.imejis.io/v1/YOUR_DESIGN_ID' \
  -H 'dma-api-key: YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "client_name": { "text": "Fairweather & Sons" } }' \
  --output proof-001.png
grep -i x-dma-warnings headers.txt
```

**The long tail of the name column.** Sort by length and render the longest and shortest. Auto-resize (`minFontSize` and `maxFontSize`) keeps both inside the box, but you still want to see what the extremes look like before a printer does.

**The rows that shouldn't be there.** Test accounts, duplicated contacts, a name field holding an email address, empty strings. A list exported from a CRM has all four. [RFC 4180](ref:rfc-editor/rfc/rfc4180.html) is the reference for what a well-formed CSV actually is, and most exports aren't quite it.

## Print and email want different files

One design, two outputs, chosen per render:

```bash
# print: single-page PDF at the design's canvas size
curl -X POST 'https://render.imejis.io/v1/YOUR_DESIGN_ID?format=pdf' ... --output card.pdf

# email: a PNG the client's mail app will actually render
curl -X POST 'https://render.imejis.io/v1/YOUR_DESIGN_ID?format=png' ... --output card.png
```

For the email half, resist the temptation to embed a live render URL in the message. Every open re-renders and costs a render, and a card forwarded around a client's office can cost you more than the card. Render once, host the file, link to that.

If you'd rather the link not live forever, signed delivery returns a time-limited URL with an `expiresAt` timestamp, defaulting to 60 minutes and capping at 7 days. [Delivery modes](/blogs/tutorials/image-api-delivery-modes) covers the choice in full.

## What a corporate holiday card API run costs

One render per recipient, per attempt.

| List size                       | Renders | Plan                              | Headroom for a re-run |
| ------------------------------- | ------- | --------------------------------- | --------------------- |
| 90 clients                      | 90      | 100 free renders a month, no card | None                  |
| 800 clients                     | 800     | Basic, $14.99                     | Slim                  |
| 5,000 clients                   | 5,000   | Pro, $24.99                       | Yes, one full re-run  |
| 5,000, print and email versions | 10,000  | Unlimited, $69.99                 | None                  |

As of September 2026 those are the plan limits. The column that matters is the last one. Budget for a re-run, because the odds that a 5,000-row list is perfect on the first pass are not good, and discovering that with no allowance left is a bad week in December. The [pricing page](/pricing) has the detail.

## Where this isn't the right tool

**We don't send anything.** No mail merge into an inbox, no postage, no address verification. You get files; your existing email platform or print partner does the delivery.

**A greeting isn't a campaign.** If you want tracking, per-recipient links and open rates, that's your email platform's job and it will do it better.

**Under about 100 cards, do it by hand.** Genuinely. Setting up a design, an export and a loop is an hour or two. For 60 cards you'd have finished by then.

The case for automating is a list in the thousands, a hard date, and the near-certainty that somebody will spot a wrong name on day two and want the batch re-run.

## Getting started

Build the card as a design, mark the name and message dynamic, and render 20 real rows with the warnings header visible. If your card carries several photos, [photo collages](/blogs/use-cases/photo-collage-api) covers multi-image layouts, and [dynamic fields](/help/dynamic-fields) explains which properties to open up. The [API docs](/apis) have batch-shaped examples in Node, Python and Go.