> ## Documentation Index
> Fetch the complete documentation index at: https://sudomock.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> The base URL is https://api.sudomock.com.
> Authenticate every request with the x-api-key header. Keys begin with sm_.
> A render returns the finished image at data.print_files[0].export_path. A request sent with is_async true returns a job_id to poll at GET /api/v1/jobs/{job_id}.
> Prefer the official SDKs over hand-written HTTP calls: npm install sudomock for Node, pip install sudomock for Python.

# Where the mockup id appears on a Shopify order

> What the customizer writes on a Shopify line item.

The mockup id is not on the order, and that is deliberate. A mockup is the
template you mapped to a product once, so it belongs to the product. What
travels with an order is the render id, which names the single image one
shopper approved.

## What the line item carries

When a shopper finishes in the customizer and the item enters the cart, the
storefront writes two properties on that cart line. They stay on the line
through checkout and onto the order.

`_sudomock_render_uuid` is the render the shopper approved. It is the handle
for that one design.

`_sudomock_action_receipt_id` is the id of the confirmation your store made
before the line was added.

Nothing else is written there. No preview URL, no artwork URL, no mockup id and
no credential. A cart property is written by the browser, so anything sitting
in one is a claim rather than a fact, and the two ids are exactly the two
values that can be checked against something we hold.

## Why a receipt id sits beside the render id

Before the item reaches the cart, your store asks us to confirm the design. The
confirmation is bound to the mockup, the render, the shop, the product and the
variant, and only then is the line added. Confirming the same design twice
returns the original receipt instead of a second one, so a retry after a
timeout cannot turn into two pieces of work. The receipt id on the line is the
id of that confirmation, which is what ties an order line back to the moment
the design was accepted.

## Where the mockup id lives instead

The mapping between a product and a template is kept on the product, in the
`sudomock` metafield namespace.

`mockup_uuid` is the template the product customizes. `mockup_type` is `psd` or
`2d`, which decides the editor a shopper meets. `customization_enabled` is
`true` while the product is live for customizing.

The app writes all three when you map a product and removes them when you
unmap it. Opening the editor needs a mapping to exist and
`customization_enabled` to read `true`, and the design confirmation is refused
when the product's `mockup_uuid` no longer matches the one the browser asked
for, so remapping a product cannot be used against an editor that is already
open.

## Reading the two properties

The app asks for product, theme and app proxy access only. It never reads your
orders and never changes them, so the properties are yours to read the way you
read any other line item property, from the order screen or through Shopify's
own order APIs.

Keep the render id beside your own order record. It is the id to quote when you
ask us about one specific design, and it is the value your fulfilment step
should key on rather than the product or the variant, because two orders of the
same variant carry two different designs.

[Customize products with Shopify](/docs/integrations/shopify) covers installing the
app and mapping a product. [Set up the editor your buyers
see](/docs/dashboard/studio) covers what the shopper meets once the mapping is in
place.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.