Build with DesignMint.

DesignMint ships as two React packages that share a single data contract. The Back Office (@intuio/designmint-back-office-sdk) is the merchant workspace where you author design rules — surfaces, print areas, physical sizes, variants, pricing. Saving it produces one serialized metadata string. The Studio (@intuio/designmint-studio) is the customer-facing canvas that consumes that metadata and turns a shopper's design into validated, print-ready output.

Your application sits between them: it persists the metadata after Back Office saves, passes it to the Studio at render time, and stores the customer's canvas data so designs can be restored later.

Both packages are published privately under the @intuio scope on npm. You need an access token from the DesignMint team — request one at designmint@intuio.io. Add it to the .npmrc in your project root (keep it out of version control), then install:

Tailwind setup. Add the package to your Tailwind content globs so its utility classes are generated, and use the class-based dark-mode strategy — the Studio follows a .dark class on your document root, not the OS preference:

The Studio is the default export and needs no providers or wrappers. Give it the metadata your Back Office produced, your priced catalog, and your backend credentials — it handles the rest:

Required props first. Money and currency codes are always lowercase (e.g. "usd").

products carries your priced catalog. Three rules matter most: every product.id must match a productId inside the metadata; money is always a per-currency record like { usd: 45 }; and color swatches appear only when every variant declares attributes.colorCode.

Unit prices resolve in a fixed order: fixed-quantity match → quantity tier → variant price → product basePrice. A tier without maxQty means "and up".

Persistence is imperative. Pass a studioRef and call its methods when you want output — the Studio never saves anything on its own:

Persist productCanvasData and pass it back on the next mount to restore the canvas exactly, decorations included. To upload the returned file content, use the bundled helpers — uploadStudioExports, uploadStudioMockups and saveBrandAssetsToDb. The upload helpers run all uploads in parallel and reject the whole call if any single upload fails, so wrap them in try/catch. Their optional authToken falls back to the stored Medusa admin token.

When a customer confirms an order, the Studio exports and uploads the files, then calls onAddToCart with one item per line: { variantId, quantity, metadata: { decorationId, files, thumbnail, personalization } }.

The Back Office takes exactly five props and talks to no backend of its own — saving is host-driven through an imperative handle, and the SDK never persists anything itself:

Validation gates saving: every design area must resolve to a print size and every required component must be linked, or save() returns success: false with a clear error list and the canvas marks the offending areas. For product cloning, the SDK exports remapMetadataIds and remapCanvasDataIds to rewrite database ids inside saved payloads, and MetadataUtils if you need to inspect metadata server-side.

Shortcuts worth learning: D design tool · P pan · Tab cycle areas · ⌘ Z/⌘ ⇧ Z undo/redo · ⌘ scroll zoom at cursor · Esc deselect.

Mounted without isAdmin, the Studio opens in the ordering view with an Edit Design expander. Customers work with exactly the tools you enabled per product: template library, styled text (with curves and effects), icons and shapes, their own uploads (JPG, PNG, GIF, SVG, DST stitch files, even custom fonts), fills and per-element color control, layers, and embroidery with live stitch counts.

The canvas keeps them honest without blocking them: live print-size badges, safety and bleed pills, and per-element warnings when artwork resolution drops below the target DPI or drifts outside the printable area. Switching a color variant swaps the product photo — never their artwork. Up to 20 saved design variations per product let them explore before committing.

Ordering is a line-item table: option dropdowns and color swatches per row, quantity as a dropdown (fixed lots) or a tier-snapping stepper, a per-row Personalize drawer for the input components you defined, and a stock guard that blocks over-stock rows. Add To Cart exports the print files, uploads them, and hands your onAddToCart callback one clean item per line.

Everything the two SDKs agree on travels in one Base64-encoded JSON string, currently format v3.0. The Back Office produces it, your application stores it, the Studio consumes it. Treat it as opaque: never parse or hand-edit it — both SDKs decode it internally, and MetadataUtils exists for the rare server-side inspection.

Round-trips are guaranteed: feeding a saved string back restores identical state. Products or variants that no longer exist in your catalog are silently filtered out on load. When you clone a product, rewrite the ids inside both payloads with remapMetadataIds / remapCanvasDataIds instead of regenerating the design work.

Still stuck? Write to designmint@intuio.io — the engineers who built DesignMint are the ones on the pager.