Polotno SDK generates business cards the way platforms actually need them generated: from data. An employee record, a CRM contact, or a signup form feeds a governed template; the render API returns a print-ready card. And when a human needs to adjust one (title change, second phone number, a longer name that needs a smaller font), the same design opens in an embedded editor instead of a support queue. This is production infrastructure for brand programs, not optional UI.
Cards are a data problem wearing a design costume
Most "business card maker API" searches come from teams automating an existing template, not designing from scratch: HR platforms provisioning cards on hire, agencies running brand programs across client teams, print platforms taking bulk corporate orders. The design is fixed; the names change. What breaks in practice is everything around the merge: names that overflow, titles that wrap, umlauts the template font lacks, and the local printer's spec (85×55 with 3 mm bleed) versus the US one (3.5×2 with 0.125").
Polotno treats the card as a data-driven document: a template JSON with dynamic variables, a render call per record, and layout behavior (text fitting, wrapping, alignment) defined once in the template rather than re-solved per card.
Key features
Template-driven generation
One governed card template; every employee, contact, or customer record renders through it. Update the template once, regenerate the fleet.
Data-source agnostic
Feed the render pipeline from your HRIS, CRM, a signup flow, or a CSV. Each record maps to template variables: name, title, phone, email, QR payload.
Long-name survival
Fixed text boxes with alignment and wrapping defined in the template mean "Aleksandra Konstantinopolskaya-Fernandez" and "Li An" both come out typeset, not overflowing.
Regional print specs
Render the same card at US, EU, or JP dimensions with correct bleed from one design. See the bleed calculator for the specs the export hits.
Human-in-the-loop editing
Open any generated card in the embedded editor for one-off adjustments, inside your product, within template governance, without a designer.
Print-ready output
PDF with bleed and crop marks, or PDF/X-1a with CMYK server-side, files a commercial printer accepts without a preflight email thread.
Example use cases
- HR platforms auto-provisioning cards for every new hire.
- Print platforms offering corporate card programs with self-serve reorders.
- Agencies managing brand-consistent cards across client organizations.
- CRM and email-signature tools generating matching card designs from contact data.
- Event platforms issuing branded contact cards for exhibitors.
Developer benefits
- One JSON template replaces a coordinate-based PDF generator and its maintenance tail.
- Batch rendering via polotno-node or the Cloud Render API.
- The bulk generation tutorial is the same pipeline. Swap the template.
- Editor and renderer share one schema, so manual edits and automated runs never diverge.
- QR codes (vCard, profile links) generated per record at render time.
FAQs
Can we generate cards without any user-facing editor?
Yes. The render API is headless: template JSON plus a data row in, PDF or PNG out. The editor is optional and additive.
How do you handle names that don't fit?
Text boxes in the template define width, alignment, and wrapping; long values typeset within the box instead of escaping it. Test the template with your longest real record.
Can cards include QR codes?
Yes. vCard payloads or profile URLs per record, generated at render time via template variables.
What about double-sided cards?
Front and back are pages of one design document and export together in order.
Which formats do printers get?
PDF with bleed and crop marks client-side; PDF/X-1a CMYK via the server-side export package for commercial print workflows.
