Skip to main content
Use this guide when you want to turn Lamina into a product feature, not just call a raw model. Each recipe below uses the same execution pattern:
  1. discover the right app
  2. inspect its schema
  3. start an execution
  4. receive results by webhook or polling
That makes the API predictable for application developers even when the underlying workflow changes.

The Real API Behind Every Recipe

The /v1 API has 24 endpoints across 9 groups. The core execution flow uses:
  • GET /v1/apps — discover apps
  • GET /v1/apps/{appId} — inspect inputs
  • POST /v1/apps/{appId}/runs — run
  • GET /v1/runs/{runId} — poll results
Additional groups — Intelligence, Publishing, Content, Templates, Assets, Account — extend what you can do after execution. See the full API Reference.

Core Contract

Authentication

Rate Limits

All /v1/* endpoints are currently limited to 100 requests per minute per IP. On 429 Too Many Requests, read these headers before retrying:
  • RateLimit-Limit
  • RateLimit-Remaining
  • RateLimit-Reset
  • Retry-After

Common Status Codes

Example Public Apps By Capability

These are example public apps observed on April 11, 2026. Use them as capability anchors in docs or demos, but pin the exact appId you want to support in production and re-check its schema with GET /v1/apps/{appId} before you ship against it.

Ecommerce Image Generation

Use this pattern for:
  • product shots
  • background swaps
  • lifestyle scenes
  • hero images
Recommended backing app example: Product Shots with Mood Board

Typical integration flow

Then inspect the chosen app and use the returned parameter names exactly:

What developers usually send

  • a product image URL or a set of source images
  • optional reference imagery
  • a prompt or creative brief
  • styling or environment choices exposed as options

What to expect back

  • one or more generated image outputs
  • occasional text outputs for summaries or metadata
  • queued or running before final media is ready

Catalog And Merchandising Automation

Catalog workflows are usually run by commerce backends, merchant tooling, or creative ops teams that need consistent outputs across many products. Recommended backing app examples:
  • Premium Catalog 1.0
  • Swift Catalog Generation
For a concrete catalog payload, the existing Quick Start example uses:
  • front image URL
  • back image URL
  • model or style options such as gender, ethnicity, body type, and location
Example execution body:
Send it to:

Good fit for

  • marketplace seller onboarding
  • catalog enrichment pipelines
  • merchandising teams refreshing seasonal collections
  • internal creative production systems

Virtual Try-On

Try-on integrations usually combine shopper-uploaded imagery, mannequin imagery, or model imagery with garment assets supplied by a commerce system. Recommended backing app example: Product Try on Suggested discovery query:
Expected input pattern:
  • one or more person or selfie image URLs
  • one or more garment image URLs
  • optional fit, pose, or styling fields depending on the app
Execution call:

Common platform pattern

  • fetch the app schema at startup or cache it server-side
  • render the form dynamically for internal tooling or merchant portals
  • pass the resulting execution ID into your job UI
  • use webhooks for completion updates instead of aggressive polling

Video Generation

Video generation follows the same app-execution pattern, but jobs are more likely to be long-running and media-heavy. This is a good fit for product marketing tools, seller studios, and content platforms generating motion assets from still inputs. Recommended backing app examples:
  • Eyewear Shoot (Multi-Shot 21s Video)
  • Performance Marketing Video (V3) Sample
Suggested discovery query:
Common input pattern:
  • one or more source image URLs
  • optional product or motion brief text
  • optional aspect ratio, duration, or style fields from app metadata
Execution call:
Use webhooks in production for video jobs. They are often long-running enough that polling is only a fallback.

Job Status And Result Retrieval

Every capability above resolves to the same status check:
Use the run ID returned from POST /v1/apps/{appId}/runs. Poll every 3-5 seconds until the run reaches completed or failed. If you are using webhooks, verify the callback signature with:

Production Guidelines

If you are building a customer-facing integration or partner API on top of Lamina:
  1. pin the appId values you support instead of relying on search at runtime
  2. re-fetch app metadata when you deploy changes to a workflow or form
  3. validate inputs against the latest parameter schema before execution
  4. prefer webhooks for long-running image and video jobs
  5. design your UI around execution states, not immediate outputs
The underlying API stays small on purpose. Most of the product-specific behavior lives in the apps you choose to expose.