Reuse one winning ad across a catalog: one edit job per SKU

Treat each SKU as its own edit job: the same winning clip as video_url, a prompt that names that SKU's product, and an Idempotency-Key unique to the SKU. A video edit takes one clip per call, so a catalog is a loop, and the loop has to respect the workspace's accepted-job capacity or later submits fail with 429 queue_full.

Runway describes its Product Swap Recipe as the fastest way to reuse a proven ad across a catalog. The Sume side below is from Generation admission and the Video Router docs, read 2026-10-01.

How many SKUs can I submit at once?

Concurrency is a dispatch limit, not a submit limit: extra valid jobs wait as queued while queue capacity remains. The ceiling is accepted job capacity, which depends on the plan.

What happens to a 200-SKU loop on a small plan?

On Pro, the 25th simultaneous paid submission would find no accepted capacity left. The API answers 429 queue_full and releases the reservation for that attempt. The docs say to stop adding work, poll existing jobs until one reaches a terminal state, cancel queued jobs you no longer need, then retry with the same idempotency key. The docs also say to prefer the live generation_limits on each submit response over this static table.

What key should each SKU use?

Build the key from the catalog id, such as ad-swap-<sku>-v1. A replay returns the original job, so a network retry never pays twice. Reusing a key for a changed prompt returns 409 idempotency_conflict; reuse keys only for exact retries. If a SKU's output is rejected, change the prompt and use a new key, as in idempotency keys for AI video APIs.

What about balance?

Each accepted job reserves its estimated cost up front. When the balance cannot cover it, the submit fails with 402 insufficient_credits before provider work starts. For a per-SKU cost estimate, see cost per SKU for AI product video, and for the single-edit call see the product swap comparison.