sume-virtual-try-on or sume-virtual-fitting: read the io profile first

The Sume catalog has two Formats whose names both point at trying clothes on a person: sume-virtual-try-on and sume-virtual-fitting. The catalog page lists both slugs and does not say how they differ, so do not guess from the names. Call GET /v1/formats/sume/{slug} for each. The response carries a description and an io profile (input_kind of url, text, image or product, and output_kind of video, image or text). Pick the one whose profile matches the asset you will send and the file you want back.

The read call

The reads need the formats:read scope. Compare the answers in a script, once, and store the choice in your config.

for slug in sume-virtual-try-on sume-virtual-fitting; do
  echo "== $slug"
  curl -sS "https://api.sume.com/v1/formats/sume/$slug" \
    -H "Authorization: Bearer $SUME_API_KEY" \
    | jq '.data | {slug, description, io, generation_spend_cap_usd_micros}'
done

What to send

The run body is the standard one. A try-on has two pictures at least, the person and the garment, and attachments takes up to 30 images, each as a public HTTPS image_url or an asset_id from the Assets API in the same workspace. Sume fetches every attachment when you create the run, so a private or broken URL fails the create with a 4xx you can act on, not minutes into the run. Use input for the facts that are not pictures: the garment name, the size label you want shown, the aspect ratio. The docs call input a free-form object that the Format reads by key, so look at the description before you invent field names.

Images referenced inside input also count. The budget is 30 files per run across attachments and input, with at most 30 images, 10 videos and 10 audio files. The same URL counts once.

Three things to set on every call

Set them the same way for both slugs, so a comparison is fair.

• Idempotency-Key derived from the garment id and a version you bump on purpose. A fresh uuid per request gives you no protection on a retry.
• generation_spend_cap_usd per run. Without it, a run inherits the Format's cap, and a Format that names none reports the platform default of $400.
• communication.webhook_url if you have an endpoint, so you take one signed terminal POST instead of polling.

Compare on three garments

Run both slugs on the same three garments and the same model photo. Use a plain tee, a printed one and one with sleeves that cross the hands. Save the receipt of each run: usage.billable_amount_usd_micros gives the spend against the cap, and the receipt is the only price evidence you should quote. The idempotency scope is one Format, so using the same key against both slugs starts two runs. That is what you want here, and it is also what you do not want in a retry loop that alternates slugs by mistake.

Keep the winner as a constant, and keep the loser's receipts. When the catalog changes, the io profile and description are the first thing to re-read.

Last, set the key scopes before the first call. A key needs formats:write to create the run and formats:read to poll it. Service-account keys cannot create Format runs at all and fail with 403 insufficient_scope, so use a personal or workspace API key. If a team workspace pays for the work, create the key in that workspace. The catalog Format itself is shared, but the run, its media and its spend belong to the key that made the call.