> ## 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.
# Create a mockup in the browser
> Build a mockup without writing a request.
The Create page is the first screen behind the login and the one place where a
mockup is made without writing a request. It takes three starting points, a
Photoshop file, a product photograph, or an image you generate, and all three
end in the same library.
## Creating mockups
Create sits at the top of the left rail in the
[dashboard](https://sudomock.com/dashboard). Whichever starting point you pick,
the page ends with a saved template carrying its own UUID, and every member of
the organization sees it and renders from the same balance.
The same work has a contract behind it. A Photoshop file and a product
photograph both register over HTTP as well, and a template made in the browser
is renderable over HTTP a second later under the same UUID, with nothing to
synchronise and nothing to register twice.
Creating and rendering both draw on the same credit balance, and the current
weights are on [pricing](https://sudomock.com/pricing). While the account is
on trial credits the result carries a watermark and a reduced width, so check
the plan before you promise a size. See
[What you can do in the dashboard](/docs/dashboard/introduction).
## Start from a Photoshop file
Upload your own file, or open one of the example templates to see the shape of
a working mockup before you commit your own. The upload reads the file and
reports every slot it can address:
* `smart_objects`, the design areas your artwork drops into.
* `text_layers`, the copy a render can replace.
* `group_layers`, the enclosing groups whose outlines a render can recolour.
Each entry carries a UUID, and that UUID is the handle a render names later, in
the browser and over HTTP alike. The rules a file has to follow are the same on
both sides, from the colour mode to the file size the dashboard accepts, so
[Preparing a PSD](/docs/psd-mockups/preparing-a-psd) applies to an upload made here
exactly as it applies to one made over the API.
Learn more about [the layers a saved template lists](/docs/dashboard/mockups).
## Start from a product photo
Upload a photograph of a real product and mark where the artwork belongs. From
then on that photograph takes new artwork the same way a smart object does, for
as long as you keep it, and you never needed a layered file to get there.
A photograph carries two kinds of render target. A print area is a bounded zone
you draw on the product, a chest panel or a poster face. The product itself
stays available underneath as one surface, so the same shirt holds a logo zone
and still accepts an all over print, and a render names one target per artwork.
[Print areas and surfaces](/docs/photo-mockups/print-areas) covers how the two are
addressed.
## Start from a generated image
When there is no photograph yet, describe the product and the scene and
generate one. Choose the product category, the aspect ratio and the style
before you generate, because those three settle the frame you will be marking
afterwards.
A generated image spends credits the way a render does, and the library keeps
what you generated, so a scene is worth generating once and reusing across a
season of designs. After that it behaves like any photograph you uploaded
yourself: mark the print area on the result, then render onto it.
## Mark where the artwork belongs
A photograph and a generated image both reach the same editor, and the marking
step is identical for the two.
The editor at
[Photo mockups](https://sudomock.com/dashboard/photo-to-mockup) opens the
result of the upload rather than an empty canvas.
A zone is four corner points and it has to sit inside the photograph. Leave
the product without zones and it still renders as a whole item.
Saving writes exactly what
[Replace the print areas of a photo mockup](/docs/api-reference/photo-mockups/replace-the-print-areas-of-a-photo-mockup)
writes, and the saved order follows the photograph rather than the order
you drew in.
The Code tab prints a ready to run call carrying the real mockup id and
target id, so the browser hands your integration its first working request.
## Find what you created
Everything the three starting points produce lands in one library, whichever
one you started from. A file uploaded in the browser takes its file name, so a
library filled from a folder of exports is worth renaming early.
Learn more about [finding, renaming and deleting what you
saved](/docs/dashboard/mockups).
## Leave the browser
The page you just used is one surface on the account rather than the only one.
The same templates and the same balance are reachable from four more, and none
of them asks you to register anything a second time.
* [SDKs](/docs/sdks) for the language you already write in.
* [Integrations](/docs/integrations/n8n) that make the call for you, with an
official node for n8n and an app for Make.
* [Connect an agent](/docs/connect-an-agent) so an MCP client renders from inside a
session.
* Plain HTTP, with a key you issue on the API keys page.
## API reference
The two endpoints behind this page are
[Create a mockup from a PSD](/docs/api-reference/psd-mockups/create-a-mockup-from-a-psd)
and
[Create a mockup from a product photo](/docs/api-reference/photo-mockups/create-a-mockup-from-a-product-photo).
Both take the same file and the same photograph this page takes, answer with
the same UUIDs, and accept a large file in the background rather than holding
the connection open.