Skip to main content
A live preview is the moment a shopper stops looking at your sample and starts looking at their own file on your product. There are two ways to build one, and the choice comes down to who moves the design.

​
Let the shopper move it

Studio is the editor you put inside your own page. Your server opens a session and the browser opens the editor with that session, so your API key never leaves your infrastructure. Your server calls Create a new Studio session with the x-api-key header. The body names the editor with mockup_type, either psd or 2d, the job with session_kind set to customize, the template with mockup_uuid, and the page that is allowed to host the editor with allowed_origin. The response carries a short lived session token, a message session id, the number of seconds the session lasts and a bootstrap secret. The page opens https://studio.sudomock.com/editor?session= with the token in an iframe, then hands the bootstrap secret to that iframe once, in reply to the first message it sends. That handshake binds one editor window to one message session. This is exactly what the official Shopify app and WooCommerce plugin do, so a custom storefront is on the same path as a supported one rather than a different one.

​
Open on the design the shopper already saw

If your page shows a grid of preview cards, the editor should open where the card was drawn, not at its own default. Seed it with artwork, one entry per target and up to eight of them, each carrying target_uuid and either a URL or base64. Add placement to say where the design starts. Every length is a percentage of the target’s own region, which is the one denominator both sides already hold, so no extra round trip is needed to agree on it. Add adjustments to carry an appearance from one mockup of a product to the next. A seeded design can be moved and restyled by the shopper, but not replaced, removed, added to or retargeted. The buyer stays inside the decisions you are willing to fulfil.

​
Take the result on your server

When the shopper is done, the editor reports studio.design-submitted. Your server confirms that report with Consume a Studio action and receives a receipt. The mockup id, the render id and the render parameters on it are ours, bound to that one render. The receipt also echoes back the artwork sources your page sent with the action, and that is where you find the image the shopper ended up with, a background removal cutout in particular. Keep those beside your own order record, and leave the render parameters exactly as they came back, because they are hash bound to the render. Confirm on your server rather than in the browser. An unconfirmed design is a claim from a page you do not control.

​
Dress it as your own

Branding, labels, which controls appear and the editor language are saved against one API key, and a single session can carry an override that is not persisted. Rendered images can be served from a subdomain you own, so the link a shopper sees carries your name instead of ours. Set up the editor your buyers see and Serve mockups from your own domain cover both, and Sell customizable products under your own brand reads them together with the storefront button.

​
Or render the previews yourself

When the shopper picks from options instead of dragging artwork, you do not need an editor at all. Render the combinations with the API and show the finished images. Keep the render wait off the shopper’s screen. Send is_async and follow the job over a webhook, and the shopper comes back to finished images rather than watching a spinner. A large grid is submitted as one batch and followed the same way, which is how most teams building on the API run this.