Certificate Generator API: The Single-Page PDF Path
A certificate generator API renders a finished certificate from a layout you designed once plus the values that change per person. Name, course, date, issue number: send them, get the file back in the response. No queue, no callback, nothing to poll.
The part that decides whether this fits your workflow isn't the certificate itself. It's the file format, and what you're allowed to do with it afterwards. So this post is about the PDF route, the expiring-link route, and the point where you should be using something else.
For the certificate on its own, certificate generation covers the setup end to end. What follows is the surrounding credential work: the ID card, the issuer's signature, and the delivery.
The job is usually three files not oneThe job is usually three files, not one
A course completion rarely produces one artifact. A bootcamp finishing a cohort ships a certificate for the wall, a badge for LinkedIn, and often an ID card for anyone attending in person. An event does the same thing in a different order.
Each of those is its own render, because a design's width and height are fixed when you build it. That sounds like extra work and it's actually the guard rail: a certificate at 3508 by 2480 and a badge at 1200 by 1200 can't accidentally share a layout and come out stretched.
Build each one free first, so you know the layout survives real data:
- Certificate maker for the wall version.
- Event ID card maker for the lanyard version.
- Signature generator for the issuer's mark, which you upload once and reuse as an image component.
None of them need a signup and none add a watermark.
Ask for pdf when it gets printedAsk for PDF when it gets printed
Format is a per-render choice, so one design serves both the screen and the printer:
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 '{
"student_name": { "text": "Priya Raman" },
"course": { "text": "Applied Statistics" },
"issued_on": { "text": "7 September 2026" },
"serial": { "text": "AS-2026-0417" }
}' \
--output certificate.pdfFour things worth knowing before you build the design around it:
- The PDF is one page, sized to the canvas. Design at the finished paper size rather than expecting a resize later.
qualityonly applies to JPEG. Setting it on a PDF render does nothing.- Renders cap at 4096 by 4096, which comfortably covers A4 at 300 DPI (2480 by 3508). Above that, drop the DPI or split the artwork.
- Fonts are embedded from the design, so a certificate opens the same on a machine that's never had your brand font installed.
Signed links for when the file shouldnt live foreverSigned links, for when the file shouldn't live forever
Streaming the bytes back is right when your server is the one storing them. When you'd rather email a link, render with signed delivery and the endpoint answers with JSON instead of an image:
{
"success": true,
"delivery": "signed",
"url": "https://storage.googleapis.com/signed-exports/...",
"expiresAt": "2026-09-07T15:04:00.000Z",
"format": "pdf"
}The default lifetime is 60 minutes and you can push it to 7 days, which is the ceiling. That covers the honest version of "here's your certificate" email: long enough for someone to find it in their inbox that evening, short enough that a forwarded link stops working. If a graduate needs a permanent copy, use hosted delivery, or re-render on request from your own dashboard.
What a rendered signature is and isntWhat a rendered signature is, and isn't
A signature drawn in the signature generator is a picture. Dropped onto a certificate as the issuer's mark, that's exactly right, and it's what a printed diploma has always been.
It is not an electronic signature in the legal sense. The ESIGN Act and its equivalents care about intent, consent, and an audit trail tying a person to a record, none of which a PNG carries. If somebody has to sign something back, that belongs with an e-signature provider. We render the credential; we don't witness it.
The same distinction applies to ID cards. A rendered card looks right and scans fine if you put a QR code on it, but the trust lives in whatever the QR resolves to, not in the card.
Where apitemplate is the better callWhere APITemplate is the better call
Our engine renders one page. If your output is a multi-page document, a 12-page report with a certificate on page one, or an invoice run that paginates by line count, APITemplate has a real document engine and we don't. As of September 2026 they list $29/mo billed annually against our $14.99, so it costs more, and for that job it's worth it.
Use us when the credential is a fixed, designed page and you're issuing a lot of them. Use them when the page count depends on the data.
What a certificate generator api costsWhat a certificate generator API costs
One render per file, every time, including a repeat of a render you already made. As of September 2026:
| Cohort | Files per person | Renders | Plan |
|---|---|---|---|
| 30 students, certificate only | 1 | 30 | Free, 100/mo |
| 400 students, certificate and ID card | 2 | 800 | Basic, $14.99 |
| 5,000 attendees, badge and certificate | 2 | 10,000 | Pro, $24.99 |
Re-issues count too, so a 5% reprint rate on a large cohort is worth adding to the sum before you pick a plan. The pricing page has the rest, and render quota explains how the counters reset.
Getting startedGetting started
Draw the certificate in the free maker until it holds a 40-character name without looking cramped, then rebuild that layout as a design and mark the fields dynamic. The API docs have working calls in Node, Python, PHP, and more, and dynamic fields covers which properties you want to open up and which to leave baked in.