Skip to main content
This guide is for product teams that want to document use cases such as image generation, catalog creation, virtual try-on, or video generation while keeping the public API reference aligned with what actually exists today.

​
Current Executable API Surface

These are the real public endpoints available today:
  • GET /v1/apps
  • GET /v1/apps/{appId}
  • GET /v1/apps/{appId}/workflow
  • POST /v1/apps/{appId}/executions
  • GET /v1/executions/{executionId}
  • GET /v1/webhooks/signing-key

​
Core Contract

Capability needCurrent executable Lamina endpoint
Start image, catalog, try-on, or video workPOST /v1/apps/{appId}/executions
Check job statusGET /v1/executions/{executionId}
Discover which app to callGET /v1/apps
Verify the exact input schemaGET /v1/apps/{appId}

​
Authentication

x-api-key: lma_your_api_key
Authorization: Bearer lma_your_api_key

​
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

StatusMeaning
200Successful read
202Execution accepted and queued
400Invalid request body, webhook URL, or inputs
401Missing or invalid API key
403Workspace or app access denied
404App or execution not found
429Rate limit exceeded
500Unexpected server-side failure

​
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.
CapabilityExample public appExample appId
Single image generationProduct Shots with Mood Boardec7ec3ce-69b4-43c9-8eea-fe9752d679a4
Batch catalog generationPremium Catalog 1.0bbb17293-5fe7-4645-8c6e-0745bc28254d
Batch catalog generationSwift Catalog Generationde5cca6b-73aa-4e27-a714-3339024db15d
Virtual try-onProduct Try ona76e85ec-20b4-4fbc-99ad-055423a868a2
Video generationEyewear Shoot (Multi-Shot 21s Video)1afc70fd-cb66-4f44-847d-bdaf7e237be4
Video generationPerformance Marketing Video (V3) Sampleec9b3525-4b72-4083-a6cb-00371672e128

​
Image Generation Recipe

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

​
How it works today

curl -H "Authorization: Bearer $LAMINA_API_KEY" \
  "https://app.uselamina.ai/v1/apps?search=product"
Then inspect the chosen app and use the returned parameter names exactly: 
curl -H "Authorization: Bearer $LAMINA_API_KEY" \
  https://app.uselamina.ai/v1/apps/<appId>

curl -X POST \
  -H "Authorization: Bearer $LAMINA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": {
      "<parameter name from GET /v1/apps/{appId}>": "<value>"
    }
  }' \
  https://app.uselamina.ai/v1/apps/<appId>/executions

​
Batch Catalog Recipe

Catalog docs should still tell the same truth: pick the catalog app, fetch its schema, then execute it asynchronously. 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/style options such as gender, ethnicity, body type, and location
Example execution body: 
{
  "inputs": {
    "Front": "https://example.com/front.jpg",
    "Back": "https://example.com/back.jpg",
    "Model Gender": "Female",
    "Location": "Studio"
  }
}
Send it to: 
POST /v1/apps/{catalogAppId}/executions

​
Virtual Try-On Recipe

For try-on docs, treat the app as the capability container. Recommended backing app example: Product Try on Suggested discovery query: 
curl -H "Authorization: Bearer $LAMINA_API_KEY" \
  "https://app.uselamina.ai/v1/apps?search=try on"
Expected input pattern:
  • one or more person/selfie image URLs
  • one or more garment image URLs
  • optional fit, pose, or styling fields depending on the app
Execution call: 
curl -X POST \
  -H "Authorization: Bearer $LAMINA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": {
      "<selfie parameter>": "https://example.com/person.jpg",
      "<garment parameter>": "https://example.com/garment.jpg"
    }
  }' \
  https://app.uselamina.ai/v1/apps/<tryOnAppId>/executions

​
Video Generation Recipe

Video generation follows the same start-then-poll pattern. The only difference is the app you pick and the media-heavy input/output expectations. Recommended backing app examples:
  • Eyewear Shoot (Multi-Shot 21s Video)
  • Performance Marketing Video (V3) Sample
Suggested discovery query: 
curl -H "Authorization: Bearer $LAMINA_API_KEY" \
  "https://app.uselamina.ai/v1/apps?search=video"
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: 
curl -X POST \
  -H "Authorization: Bearer $LAMINA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": {
      "<image parameter>": "https://example.com/product.jpg",
      "<prompt parameter>": "Create a premium ecommerce product reel"
    }
  }' \
  "https://app.uselamina.ai/v1/apps/<videoAppId>/executions?webhook=https://your-server.com/callback"
Use webhooks in production for video jobs. They are often long-running enough that polling is only a fallback.

​
Job Status Recipe

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

​
Important Documentation Rule

Do not document endpoints that do not exist yet. If you want a future wrapper API such as /v1/images/generate, build and ship that backend contract first. Until then, public docs should describe the real Lamina Apps API endpoints above. For a polished public docs experience with the current backend:
  1. keep the API Reference limited to the real /v1/... endpoints
  2. use this page to explain business use cases like image generation or try-on
  3. pin one or more production-ready appId values for each documented use case
  4. keep examples synchronized with the actual parameter schema from GET /v1/apps/{appId}