Use case
Product clips, one per line in your catalogue
Generate a clip per product from your own catalogue data. Cost is per second and known before the run, so a large batch is arithmetic, not a surprise.
One clip per product is an arithmetic problem
A catalogue of a few hundred products needs a few hundred clips, and the only question that matters is what that costs and whether the number holds.
Rendering is billed at 30 credits per second of finished video. Total cost is total seconds, and nothing else moves it. A quote endpoint will tell you the figure for a request before you commit, which makes a batch something you can budget rather than something you discover.
The shape of the job
Read your catalogue. For each product, write a short script from the fields you already have, and submit it with a person. Collect the run ids, poll them, and write the finished files back against the product record.
That is a loop you can run nightly over products that do not have a clip yet. It does not need a browser open, and it does not need anyone watching it.
Failures inside a batch
A large batch will have failures. The useful property is what they cost.
Billing starts when the vendor accepts the paid render of your clip, and not before. A run that breaks earlier costs nothing, and a run that breaks because of us costs nothing either, even when we have already paid the vendor. A retry pass over the failures is safe to run, which matters when a batch is large enough that some attrition is certain.
Variants for testing
The cheapest way to find a clip that works is to render several and let the numbers decide. Different scripts, different people, same product.
Because cost is per second, a set of variants is priced the same as one long clip of equivalent length. There is no per-variant surcharge to reason about.
What to plan around
Clips are kept for 30 days after the run and then deleted, so the file belongs in your own storage on the same pass that created it.
Clipwright does not post anywhere. Getting the clip onto a product page, into an ad account, or anywhere else stays in your pipeline.
Start
A batch over a whole catalogue is easy to start and awkward to undo. Render one product first, decide from that file, and only then write the loop.
Checked on 2026-09-15.
Questions
- Can I generate a clip for every product automatically?
- Yes, if you can iterate over your catalogue. Each product becomes one request carrying a script and a person, and each returns a run id you poll. A nightly job over new products is the usual shape.
- How do I keep the cost predictable across a large catalogue?
- Rendering is 30 credits per second of finished video, so cost scales with total seconds, not with which features you happened to use. Ask the quote endpoint first if you want the figure before the batch starts.
- What about products that fail?
- You are charged only once the vendor has accepted the paid render of your clip. A failure before that point costs nothing, and so does a failure caused on our side, even when we have already paid the vendor. A batch with failures does not bill you for them.
- Can I use my product photo?
- You can supply a photo as the identity for the person in the clip. The clip is a person speaking your script, not a product tour, so treat it as a spokesperson asset rather than a replacement for product photography.
- Where do the finished files go?
- They are returned as files and kept for 30 days, then deleted. Copy them into your own storage or your product records as part of the same job that generated them.
Render a clip and compare the files yourself.