BlogContact

I Built a Product-Video Approval Loop From Catalog Data

I used to treat every new product video as a tiny creative project: pick a product, hand over images and copy, wait for a cut, find a bad price or missing variant, then start the loop again. That is manageable for a launch. It falls apart when you want a short video for 200 catalog items.
The change that made the workflow usable was separating the product data from the video decision. The catalog supplies the ingredients; a template supplies the design; a human reviews a draft before an MP4 exists. VideoFlow is a good fit for that middle layer because the video is portable JSON, not an opaque export you cannot inspect or reuse.

Start with a boring, reliable catalog record

I would not begin with an AI prompt like “make a nice product video.” I would begin with a small, explicit record for every SKU or product family:
  • title and short feature line
  • price, compare-at price, and currency formatting
  • approved image URLs or video clips
  • variant name and availability
  • destination URL and CTA
  • a template key, locale, and campaign label
That list sounds unglamorous, which is exactly why it works. A render queue can tell you which field is missing. A reviewer can tell whether the right variant was used. And the same source can later make product-page clips, ad variations, or a launch-email asset without re-keying the offer.
For a Shopify team, I would also decide up front whether color is a variant or a linked product. That sounds unrelated to video until a blue chair clip shows a price from the beige chair. The same data-model discipline behind linked-product swatches keeps a catalog-video workflow honest.

Put the reusable design in a template

The template should own the things you want to protect: scene order, type scale, safe margins, animation timing, transition choices, and which fields can change. The catalog record should own the things that genuinely vary.
With VideoFlow Core, a developer can define scenes in TypeScript and compile them to VideoJSON. That gives the workflow a practical source of truth between “we have product data” and “we rendered an MP4.” You can store it, diff it, validate it, hand it to a reviewer, and render it again later.
My first template would be short: a three-second product reveal, one feature beat, a price or offer beat, then a CTA. It is much easier to learn from a 12-second video than to diagnose a 45-second one with six places for a catalog mismatch.
The important operational rule is this: make a draft document for every product, not a final video. If the price changes, regenerate the document. If the creative rules change, update the template. You do not need to recreate the workflow.

Review the draft where corrections are cheap

This is where I stop wasting rendering time. Mount the VideoJSON in a live preview, check the actual product, price, crop, CTA, and duration, then approve it. VideoFlow’s DOM renderer is designed for a scrubbable preview of the same document that will be exported.
For teams that need more than approve/reject, the React Video Editor gives you a more useful handoff: a multi-track timeline, trimming, ordering, keyframes, effects, and MP4 export around the same VideoJSON. I would keep the editable surface constrained. Let a merchandiser swap an approved image, shorten copy, or adjust timing; do not turn a catalog job into an unrestricted editing suite.
That middle review is the part I wish more automation projects added. In a customer-recap workflow, I found that approving the structured draft first was more sensible than rendering an asset nobody had signed off on. The same lesson applies here: render only after the video is approved.

Choose the renderer after approval

A lot of teams make this decision too early. The document can stay the same while the delivery path changes.
Use the browser renderer when a user is making a small export in your app and you prefer not to upload source material or pay for server capacity. It supports progress feedback and cancellation, which matters when an operator changes her mind halfway through.
Use the server renderer when you need scheduled batches, an API, reliable background jobs, or many variations. That is the route I would choose for a nightly catalog refresh or an event-triggered product launch. Keep the job payload small: VideoJSON version, template version, approved asset URLs, output dimensions, and a destination. If a job fails, you can retry a precise document instead of reconstructing a creative brief.
This is also why a queue article and a localization article are complementary, not interchangeable. A JSON rendering queue solves delivery at scale; localized VideoJSON variants solve reuse across markets. The approval loop makes sure you only send the right work into either system.

The checks I would make non-negotiable

Before I allow a render job to leave the queue, I would check:
  • every media URL resolves and belongs to the approved product
  • the price and currency are current
  • copy length fits the template’s safe area
  • the intended variant, locale, and CTA match the destination URL
  • the template and VideoJSON versions are recorded
  • a reviewer has approved this exact draft
None of these checks are creative. They are the difference between a useful automation and a fast way to distribute a wrong offer.

A practical first rollout

Pick ten products with consistent photography. Build one narrow template, generate ten previewable VideoJSON documents, and ask the person who owns merchandising to approve or reject them. Track the rejection reason. If most fixes are image crops, tighten your asset rules. If copy overflows, change the template rather than asking people to rewrite every SKU.
Then render the approved set through the route that matches the job: browser export for an operator’s one-off, server rendering for the batch. That is the point where VideoFlow’s core, preview, editor, and renderers become more than a programmatic-video toolkit. They become a sensible operating system for repeatable product video.
My next action would be to define one catalog record and one 12-second template before building anything larger. If that handoff is reviewable, your video automation can grow without becoming another opaque production queue.