Polotno SDK is the creation layer for photo-product platforms: photobooks, calendars, wall art, and photo gifts. Customers compose their photos inside your app on canvases sized to your products; your backend gets print-ready files and re-renderable design JSON. Multi-page documents, image-resolution safety, and template governance are the parts of this category that hurt to build in-house. They come with the SDK. This is production infrastructure for fulfillment, not optional UI.
The photo-products editor problem
A photobook editor is one of the harder editors to build from scratch: dozens of pages per project, hundreds of user photos per session, layout templates that must stay printable after every edit, and customers who work on a project across multiple visits. Teams that build this in-house discover the real spec after launch: autosave and resume, low-resolution warnings before the order (not after delivery), spreads and page order surviving export, and the day a customer uploads 400 photos from a phone.
Polotno ships that spec: multi-page documents in one JSON schema, per-element image-resolution checks, templates with locked layout and open photo slots, and export pipelines built for print.
Key features
Multi-page projects
Photobooks and calendars are first-class: pages, spreads, and page order live in one design JSON, survive editing sessions, and export in order to a single print-ready PDF.
Resolution safety
Every image element exposes its effective DPI at print size. Warn or block at upload time, the cheapest possible place to catch the blurry-print refund.
Layout templates with governance
Ship layout libraries (grids, collages, themed pages) where the structure is locked and the photo slots and captions are open. Customers get creative freedom that can't produce an unprintable page.
Save and resume
Designs serialize to JSON in your database. Customers leave mid-project and pick up where they stopped, on another device, in another session.
Print-ready export
PDF with bleed and crop marks client-side; PDF/X-1a with CMYK via the server-side export package. Calendars and books preserve pagination.
Auto-fill and smart layouts
Generate a first-draft book programmatically. Pull the customer's photo set into layout templates via the API, then let them refine in the editor. Starting from a 40-page draft converts better than starting from page one.
Example use cases
- Photobook services with in-browser book building and multi-session editing.
- Photo calendar products with date grids locked and photo areas open.
- Wall-art and canvas-print stores with live crop, framing, and DPI checks.
- Photo-gift catalogs (mugs, puzzles, blankets) sharing one editor across SKUs.
- School and sports photography platforms batch-generating personalized products.
Works with your print backend
The export side pairs with any print API. Documented integrations include Gelato (photo products, local production), Prodigi (fine art and photo products), Peecho (books and magazines), and Lulu (books). See all integrations.
Developer benefits
- One schema for a 2-page card and a 120-page photobook.
- Image-resolution validation before the order is placed.
- Programmatic first drafts from a photo set via the API.
- Client, self-hosted, or cloud rendering as volume grows.
- Design JSON stays in your database. Reorders and re-edits are free.
FAQs
Can it handle a 100+ page photobook?
Yes. Pages are entries in one JSON document; the editor virtualizes rendering and export walks pages in order.
How do we stop customers ordering blurry prints?
Per-element resolution checks against the product's print size, surfaced in the editor at upload, before checkout, not after delivery.
Can we auto-build a book from uploaded photos?
Yes. Generate the design JSON programmatically from layout templates and the photo set, then open it in the editor for refinement.
What export formats are supported for print?
PDF with bleed and crop marks client-side, PDF/X-1a with CMYK server-side, plus high-resolution raster per page where the printer wants images.
Do reorders require the customer to redo anything?
No. The design JSON in your database re-renders on demand: same product, different size, or updated print spec.
