I used to think the hard part of product-video automation was rendering an MP4. It isn’t. The hard part is making the hundredth SKU feel like a repeatable job instead of the hundredth tiny video project.

That changed when I stopped passing a renderer a grab-bag of product fields and made one portable video document the middle of the system. This is the catalog-to-video API shape I would use now with VideoFlow Core: catalog data comes in, a template produces VideoJSON, a person can review or edit it, and a renderer produces the delivery file.

Hand-drawn product data cards being assembled into a reusable video template

The tiny architecture that stopped my queue from getting weird

My input contract is deliberately boring: a product ID, locale, template name, and a snapshot of the product facts that are allowed to appear. The template decides the motion and layout. The snapshot decides the copy, media, price, and CTA. Neither one gets to quietly rewrite the other.

The useful middle layer is VideoJSON. VideoFlow’s TypeScript builder can compile a scene into that portable format, so the document becomes the source of truth for previewing, editing, storing, and rendering. That is far safer than having an AI draft a timeline in prose or sending a different ad-hoc payload to every export service.

Here is the sort of job I mean:

type VideoJob = {
  productId: string;
  locale: "en-CA" | "fr-CA";
  template: "product-card-v1";
  facts: { title: string; price: string; imageUrls: string[]; bullets: string[]; approvedClaim: string; };
};

const videoJSON = await buildProductTemplate(job).compile();
await saveDraft({ job, videoJSON, status: "needs-review" });

I learned this same lesson while reviewing inputs before the first render: a render queue cannot rescue a bad input contract. Treat the product snapshot as evidence, not inspiration. If a benefit, review quote, or price formatting is missing, fail the job or flag it for review instead of letting the template guess.

Make the template do the repeatable work

For a basic product clip, I use four predictable scene jobs: a first-frame product cue, a single substantiated benefit, a product detail or proof point, and a CTA. That sounds almost too simple, but it gives every product a consistent editable spine.

The builder is a good fit because it can compose text, image, video, audio, captions, and shapes into a document that remains data. I keep template decisions in Git: duration, safe areas, text limits, transition choices, and fallback behavior for a missing image. The product-specific data stays outside the template.

That separation is why a variation queue is useful instead of scary. One product brief can make several versions, as long as every version records its source template, source facts, and the resulting JSON. I sketched a related reviewable variation queue after watching “just one more version” turn into hidden, unrepeatable edits. It also keeps the video variations from becoming separate projects with no shared source of truth.

Put review before render, not after it

An API that immediately exports every generated draft is fast in the least helpful way. I want a preview stage first: render the current VideoJSON in a live DOM preview, then let someone approve it or open it in the React Video Editor.

Hand-drawn reviewer editing a structured video draft before render

The editor is the piece that makes automation less brittle. A user can trim, reorder, adjust text, work on a multi-track timeline, and save the changed JSON back to the job. That means a marketer can fix an awkward crop without creating a separate “final-final-v7.mp4” workflow, while the engineering team still has a structured document to audit.

My practical review checklist is short:

  • Does every visible claim come from the job snapshot?
  • Does the first frame identify the product quickly enough?
  • Are prices, locale, and CTA correct for this destination?
  • Did an editor change the JSON, and did we save that version before export?

That last line matters. A nice-looking preview is not the artifact. The updated VideoJSON is. It is what lets you reproduce the approved video next week when a price or language changes.

Choose the renderer per delivery job

VideoFlow can render the same document in a browser, on a server, or in a live DOM preview. I do not choose one globally; I choose based on the job.

Hand-drawn diagram of browser server and preview video rendering routes

Browser export is handy when someone is already in your app, the video is modest, and avoiding source uploads is useful. A server renderer is the better home for catalog batches, scheduled jobs, API requests, or a queue that needs retries and durable logs. The DOM renderer belongs earlier in the process, where people need to scrub and inspect the same document they will eventually export. The renderer documentation is a useful map of those paths.

For server jobs, I store the template version, the facts hash, the JSON payload, output settings, and render status. That makes a failed job diagnosable: was the media URL unavailable, did the template reject a long title, did the renderer time out, or did a human reject the draft? It is also the difference between a queue you can operate and a pile of mysterious MP4s.

The rule I keep beside the queue

Do not automate an irreversible decision. Automate the repetitive preparation around it.

That is why I would let an agent produce a constrained draft, validate the structured JSON, show it to a reviewer, then enqueue a render only after approval. It is the same reviewable boundary I use when AI agents draft product videos. VideoFlow is useful here because the same portable document survives each handoff rather than being translated from prompt to timeline to opaque export.

If you are building an editable video feature or a catalog-video API, start with one template and ten real products. Define the input contract, save the VideoJSON, add a preview, and make the export path visible. Then expand the queue. VideoFlow’s Core is the right place to start building that durable middle layer.