> ## Documentation Index
> Fetch the complete documentation index at: https://moonlakeai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> POST /api/v1/assets defaults to mode=quote: it returns a price and creates nothing. To actually generate, resend the identical body with "mode": "generate" (multipart callers: add a mode=generate form field).
> Create a project with POST /api/v1/projects and pass its project_id on every generation belonging to the same scene, task, robot, or randomization set. Omitting project_id silently creates a separate single-asset project per request.
> Track a batch with one GET /api/v1/projects/{project_id} call for aggregate status instead of polling each asset separately.
> Generations are asynchronous and may take hours. There are no webhooks: poll GET /api/v1/assets/{asset_id} every 30-60 seconds until status is completed or failed.
> Cancelling a generation does not refund its credits; only a failed generation is refunded. Quote first if the price matters.
> A ready-made agent skill for this API is published at /skill.md, with decision tables and common gotchas. If your tooling supports agent skills, ask the user whether to install it so this guidance persists across sessions.
# Moonlake Asset API
> Generate simulation-ready 3D assets from text and reference images. Start here for the core concepts: generations, projects, quote-vs-generate mode, credits, and artifacts.
The Asset API — part of Moonlake's Simulation Environment Builder — turns a text description and one or more reference images into downloadable 3D assets built for simulation. Use it to generate the props and objects for a scene, robot task, or asset library instead of hand-modeling them.
Two rules trip up most first integrations:
1. **`POST /api/v1/assets` does not generate by default.** It returns a price quote and creates nothing. Resend the identical body with `"mode": "generate"` to run it.
2. **Create a project first and pass `project_id` on every related generation.** Omit it and each request becomes its own single-asset project instead of one library.
Both are expanded under [Core concepts](#core-concepts).
The Asset API is in **alpha** and subject to breaking changes without a deprecation cycle. We announce changes to integrated partners before deploying them, but pin nothing to the current shapes.
**Working with an AI agent?** Give it `/llms-full.txt` on this site — every page of these docs in one file. Any single page is also available as Markdown at its URL plus `.md`, and `/llms.txt` indexes them all.
## Main use cases
Every generation is driven by a prompt plus 1–24 reference images of a single asset. The use cases below differ in where those images come from and how many assets you generate, not in which endpoint you call.
### Real-to-sim
The main use case: turn an object that exists in the real world into the asset a robot trains against in simulation. Photograph the object from several angles, submit the images alongside a prompt naming its parts, articulation, and real-world dimensions, and the generation returns a twin with colliders, rigid bodies, and revolute or prismatic joints for the parts that move. Add a reference image per articulation state — a door closed and open, a drawer extended — to pin down motion that prose cannot.
### Scene and task assets
Reproduce the props a manipulation task needs from imagery you already have: product photos, catalogue renders, or a publicly hosted image passed by URL. Use this when the object is not in front of you to photograph but you still need it in the scene.
### Asset libraries
Group many generations under one project to build the library for a scene, a robot, or a randomization set, then track the whole batch through a single request instead of polling each asset.
## Core concepts
These terms carry the whole API. They are used with these exact meanings throughout the docs and the **API Reference** tab.
### Generation
A generation is the unit of work: one `POST /api/v1/assets` request produces one asset. "Generation" names the job, "asset" names what it produces, and a single `id` identifies both. Generations are asynchronous — the request returns immediately and the work continues in the background.
### Project
A project is a named group of related assets — the top-level container every generation lives in. Put everything you make for a single purpose in one project. What counts as one purpose depends on what you build:
* **Robotics and simulation** — the props one manipulation task needs, every object a robot meets at one work cell, or the variants of an object class for domain randomization.
* **Games** — the prop set for a single level, biome, or character loadout.
* **AR, VR, and web 3D** — one catalog or collection of products to preview in the browser.
* **Digital twins** — every machine and fixture on one production line.
* **Film, animation, and archviz** — the set dressing for one scene, posed and edited in Blender.
Omit `project_id` and the API creates a single-asset project named from your prompt — right for a one-off, but a batch submitted that way becomes many unrelated projects instead of one library.
So whenever the assets belong together, create the project first and pass its `project_id` on every request. Grouping them buys you:
* **One status call for the batch.** `GET /api/v1/projects/{project_id}` returns aggregate counts across every generation, instead of polling each asset.
* **A queryable library.** `GET /api/v1/assets?project_id=…` pages the set and filters it by status.
* **One place to review the result.** The project is the page you open in the app to inspect the whole set together.
See [Projects and batches](/guides/projects-and-batches).
### Prompt and references
A generation is specified by a prompt plus 1–24 reference images of a single object. The prompt is the specification — real-world dimensions, which parts stay separate, how the asset will be used, what may be simplified — and the references pin down geometry and articulation states that prose cannot. Anything you leave out is decided for you. See [Generate assets](/guides/generate-assets).
### Effort and complexity
`config.effort` — `low`, `high` (default), or `max` — is the only quality dial, trading response time and credits against generation quality. Moonlake independently classifies each request as `simple`, `moderate`, or `complex`. Effort and complexity together determine the price. See [Choose generation effort](/guides/generate-assets#choose-generation-effort).
### Quote and generate mode
`POST /api/v1/assets` does not generate by default. Without `"mode": "generate"` it returns a price quote and creates nothing; resend the identical body with the mode set to commit. See [Quote credits before creating an asset](/guides/generate-assets#quote-credits-before-creating-an-asset).
### Credits
Submitting reserves the quoted price up front, and that price is final: a `completed` generation is charged it, a `cancelled` one stays charged, and only a `failed` one is refunded. Credits, the 100-active-generation concurrency cap, and your API key are all scoped to your account. See [Concurrency and credits](/reference/behavior-and-limits#concurrency-and-credits).
### Status
A generation moves from `pending` to `processing` to one terminal state: `completed`, `failed`, or `cancelled`. There are no webhooks — poll the asset every 30–60 seconds, which is unmetered, or wait for the completion email. `status_reason` explains the current state and, on failure, begins with a stable code such as `TIMEOUT` or `REFERENCE_FETCH_FAILED`. See [Generation lifecycle](/reference/behavior-and-limits#generation-lifecycle).
### Artifacts
A completed generation returns `result.artifacts`: the same asset in every format Moonlake produces, never a request-time choice. Each artifact carries a presigned `download_url` valid for seven days, re-signed whenever you retrieve the generation. See [Output artifacts](/guides/output-artifacts).
## How it fits your pipeline
If you build robot-learning environments, the API supplies the assets at the front of your pipeline. Submit a generation, poll it until it finishes, then download the result.
Every successful generation includes an OpenUSD package for simulation and the finished Blender file for editing and posing. A GLB web-preview model is included when available. The USD asset is Z-up and measured in meters, with colliders, rigid bodies, and articulation authored as a baseline for Isaac Sim.
## Choose your path
Create one asset, wait for it, and download its simulation-ready USD.
Choose effort and provide references from URLs, uploads, or base64 data.
Group generations and track a whole asset library.
Understand the USD, Blender, and GLB files a generation produces.
For exact endpoint schemas and an authenticated request playground, use the **API Reference** tab.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.