Multi-view catalog

One request. Front, ¾, side, back. Same person. Same garment. No drift.

#Why catalog mode

E-commerce PDPs need 4–5 views of the same look. Calling /v1/images/tryon four times independently produces four different-looking people wearing four slightly different garments. Catalog mode chains them: view 0 renders first, then its output is passed back as an identity_lock reference for views 1..N.

#Sending the request

Pass an array of views instead of a single value. The API automatically creates a parent type=catalog job and one child image_tryon per view.

bash

curl -X POST https://garmentverse-api-807711804803.asia-south1.run.app/v1/images/tryon \
  -H "Authorization: Bearer $GARMENTVERSE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "garment_to_person",
    "person_image": "<person_id>",
    "garment_image": "<garment_id>",
    "garment": { "category": "lehenga" },
    "views": ["front", "three_quarter_left", "side", "back"],
    "tier": "premium",
    "consent_token": true
  }'

#Job lifecycle

Parent job: queued → running → succeeded | failed.
Each child runs in order. View 0 establishes the identity anchor; a failure here fails the parent fast.
Later view failures mark the parent as failed but successful sibling outputs are kept — re-submit just the missing views.
Parent cost_credits is the sum of child costs once everything settles.

#Fetching outputs

GET /v1/images/{parent_id}/outputs aggregates all children. Each item carries the view it was rendered for, so you can map them straight to your UI tabs.

bash

curl https://garmentverse-api-807711804803.asia-south1.run.app/v1/images/$PARENT_ID/outputs \
  -H "Authorization: Bearer $GARMENTVERSE_API_KEY"
# → [
#   { "id": "out_a", "file_id": "file_…", "view": "front" },
#   { "id": "out_b", "file_id": "file_…", "view": "three_quarter_left" },
#   ...
# ]

#Billing

N views = N billed calls at the tier rate. There is no extra catalog overhead — you pay exactly the per-image price for each rendered angle.

#Tips for consistency

For the highest fidelity across angles, use tier: "premium" — the router prefers specialist try-on models that handle garment continuity better than general-purpose models.
Keep the same background across views (the default studio_white is best for catalog).
Pass the same garment subtype in all views — for sarees, swapping subtype between angles will shift the drape.
Use idempotency_key on the parent so retries don't fan out twice.

Need just one view? Pass views: ["front"] and the request stays a single image_tryon job, no fan-out.

Companion recipe in the cookbook.