leonardo-image

What it does

Operate Leonardo.Ai's official Production API for still images. Keep native Leonardo models, partner models hosted by Leonardo, realtime-canvas endpoints, and legacy endpoints visibly separate: they have different routes and schemas.

How it works

• Start with a production brief collecting deliverable details (subject, setting, style, composition, dimensions, output count, acceptance criteria).
• Specify operation type (text-to-image, image-to-image, reference guidance, masked edit, upscale, background removal, or custom training).
• Provide source media (local paths or Leonardo image IDs), whether uploaded or generated, and intended role of each reference.
• Define rights, privacy, and visibility; specify runtime (REST, official Python SDK, or official TypeScript SDK).
• Include spend controls (calculator estimate, hard budget, concurrency ceiling, and whether auto-top-up is disabled).
• Before any paid call, state exact route, model/model ID, settings, sample count, calculator estimate, and why; await explicit approval. Do not silently change model, visibility, reference method, quality mode, or sample-to-batch scope.
• Use two-step image upload for references: init via POST /api/rest/v1/init-image then presigned upload with fields and binary to the returned URL; delete unused uploads with DELETE /api/rest/v1/init-image/{id}.
• For edits and guidance, use current controlnets, inpainting, and image guidance structures; prefer current native endpoints and model guides.
• When scaling/upscaling, choose appropriate Pro Upscalers via POST /api/rest/v2/generations or legacy universal-upscaler, with model and parameters as described (e.g., aurora-upscaler-precise or aurora-upscaler-creative).
• For elements and custom models, follow the Element flow (datasets, uploads, element creation, polling, and generation using userElements).
• Iterate prompts and references following the prompting and iterative craft guidance, recording all relevant IDs, seeds, and configuration details.
• Webhook-first async lifecycle is supported; use GET /api/rest/v1/generations/{generationId} to poll status (PENDING, COMPLETE, FAILED) and interpret generated_images accordingly.

When to use it

Use when implementing Leonardo image API, handling async polling or webhooks, enforcing dry-runs and cost governance, securing artifacts, iterating prompts, or troubleshooting production image generation workflows. Do not use for Leonardo video, 3D generation, unofficial wrappers, or third-party gateway APIs.

What it can touch

• Endpoints for generations (POST /api/rest/v1/generations, POST /api/rest/v2/generations)
• Initialization and upload (POST /api/rest/v1/init-image, related presigned upload)
• Inpainting (POST /api/rest/v1/lcm-inpainting)
• Upscalers (POST /api/rest/v2/generations with specific models) and universal upscaler (POST /api/rest/v1/variations/universal-upscaler)
• Elements and custom models flows (/api/rest/v1/datasets, /api/rest/v1/elements, /api/rest/v1/models)
• Status polling (GET /api/rest/v1/generations/{generationId})

Caveats

• Do not mix v1 and v2 model shapes; use v2 only for models whose guide defines that shape. Ensure public is false for private production requests. Prompt, dimensions, and other fields must follow current model guides and calculator outputs.
• The workflow requires explicit approval before paid calls and careful handling of references, model choice, and visibility settings.
• Specific parameter ranges (width/height, prompts, seeds, etc.) depend on current model guides and may conflict across sources; validate with Get API Code and calculator before production.
• The skill excludes video endpoints, 3D generation, MCP proxies, and unofficial SDKs.
• Training or elements are optional and must be justified given data rights and cost considerations.