Zvid

How We Turned 5,400+ Shopify Products into Videos in One Day with n8n and Zvid

Mina Ramzy — Fri, 14 Aug 2026 13:14:48 GMT

A Shopify client wanted a product video for every item in a catalog of more than 5,400 products.

At first, this sounds like a video-editing problem. At that scale, it is really a data, orchestration, and quality-control problem.

If a person spent only 10 minutes on each video — selecting images, adding product details, checking the result, exporting it, and attaching it to the right product — the catalog would still require about 900 hours of work. That is more than 112 eight-hour working days.

We converted the catalog within one day by studying the product data first, defining one reusable creative system, and automating the controlled parts of the process with n8n, Shopify, and Zvid.

What we learned from the catalog

The first step was not rendering. We inspected the catalog to understand:

which products had public, usable images;
how titles, prices, descriptions, variants, sizes, vendors, and product types were stored;
which products already had Shopify video media;
which brand and layout decisions could be shared; and
which product identifier could safely connect each rendered MP4 back to its source.

The answer to the last question was the Shopify product GID. Titles can change and can be duplicated. The workflow therefore carries the product GID from the catalog query through the Zvid batch and back into the Shopify publishing request.

The workflow

The n8n workflow follows this sequence:

Manual or daily trigger
  → query active Shopify products
  → skip existing video and incomplete product data
  → map catalog fields into one shared Zvid design
  → validate and quote the batch
  → create an editor preview or render the batch
  → return review links
  → optionally stage, attach, and tag each Shopify product

Each product can contribute up to four images, its title, first-variant price and compare-at price, three description points, available sizes, vendor, product type, storefront URL, and color-related styling.

The workflow builds one vertical video design and one variable set per eligible product. Sharing the design keeps the output consistent and avoids rebuilding thousands of timelines.

Why the workflow checks existing media twice

The default Shopify search excludes products tagged zvid-video. That tag lets later scheduled runs move through the catalog instead of selecting successfully processed products again.

The workflow also reads Shopify product media. A product with non-failed VIDEO or EXTERNAL_VIDEO media is skipped even when it does not have the processed tag. This protects products that received video from another process.

Products without a title, public image, or priced variant are also skipped and reported instead of causing the whole batch to fail.

Safe defaults before spending credits

Two controls are enabled in the downloadable workflow:

dryRun: true
publishToShopify: false

In dry-run mode, the workflow validates the project, returns the approximate duration and exact credit quote, and saves the first resolved product as an editor draft. It does not start the paid batch render.

After the design is approved, changing dryRun to false starts rendering. Keeping publishToShopify set to false returns MP4 review links without modifying product media. Automatic publishing is enabled only after those outputs are approved.

Reliable Shopify publishing

Publishing a hosted Shopify video requires more than sending a URL to a normal product-update action.

The workflow:

reads the rendered MP4 size and MIME type;
requests a secure target with Shopify's stagedUploadsCreate mutation;
uploads the MP4 to Shopify staging;
associates the staged resource with the matching product using GraphQL; and
adds the processed tag only after Shopify accepts the association.

If a render, upload, or association fails, that product is not tagged. It stays eligible for a controlled retry.

Authentication

Shopify uses an Admin API access token in the X-Shopify-Access-Token header. This token is not the app's Client ID or Client secret. Create and install the Shopify app with the least-privilege scopes needed by the workflow: read_products, write_products, and write_files. Exchange the app credentials for the Admin API token, then store that token in one n8n Header Auth credential.

For Zvid, a workspace owner or admin may need to install @zvid/n8n-nodes-zvid from Settings → Community nodes. Create a Zvid API key at app.zvid.io/api-keys, store it in a Zvid API credential, and reuse that credential across the Zvid steps.

Never place either secret in the Config node or exported workflow JSON.

Why some steps use HTTP Request nodes

The bulk render uses the published Zvid community node. The workflow retains HTTP Request nodes where it needs API shapes not exposed by a standard action, including the advanced Shopify GraphQL media flow, first-product variable validation, editor-draft creation, and bulk-status polling.

This also avoids depending on Shopify's legacy REST Product resource for a workflow that needs exact media, image, description, variant, staged-upload, and tag mutations.

What made the one-day result possible

The main optimization was not a faster editor. It was a better production model:

catalog data became the source of truth;
one design became thousands of product-specific outputs;
stable IDs preserved product-to-video mapping;
batch limits controlled cost and failures;
validation happened before rendering; and
Shopify writes remained behind an explicit approval flag.

That combination let us process more than 5,400 products within one day while retaining a reviewable, repeatable workflow.

Get the workflow

Watch the walkthrough: https://youtu.be/qe5KHfJoZmY
Download the n8n template: https://n8n.io/workflows/17932-create-and-publish-shopify-product-videos-with-zvid/
Try Zvid: https://app.zvid.io
Read the Zvid documentation: https://docs.zvid.io

JSON to Video API: Convert JSON to Video with Zvid

Mina Ramzy — Tue, 09 Jun 2026 11:38:23 GMT

A JSON to video API lets you describe a video as structured JSON data, submit that payload to a rendering endpoint, and receive a finished video file when the job completes. If you need to convert JSON to video for templates, localization, product feeds, campaign variants, or app-generated clips, that is usually a better fit than rebuilding timelines manually in a GUI.

The core workflow is simple: verify your API key, submit a payload with a POST request to /api/render/api-key, save the returned jobId, and poll GET /api/jobs/{id} until the render completes. Zvid documents that exact flow in the Getting Started guide, the Authentication guide, and the JSON Structure overview. If you are evaluating the broader automation pattern, the same principles also appear in How to Generate 1,000 Videos Automatically with an API and How to Create Product Videos from a CSV or Product Feed.

A JSON-to-video workflow turns structured inputs into repeatable renders.

Here is the public API shape most teams start with:

curl -X GET https://api.zvid.io/api/user/profile \
  -H "x-api-key: YOUR_API_KEY"

curl -X POST https://api.zvid.io/api/render/api-key \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d @render-job.json

curl -X GET https://api.zvid.io/api/jobs/$JOB_ID \
  -H "x-api-key: YOUR_API_KEY"

That request pattern matters more than any single example video. Once your application can generate valid payloads, submit jobs, and track results, the same system can power demos, onboarding videos, product videos, internal ops videos, ecommerce clips, or high-volume personalized output.

What a JSON to video API actually does

A JSON to video API separates video intent from video rendering.

Instead of storing a timeline only inside an editor, you send a structured description of the scene: canvas size, duration, background, visual layers, audio tracks, subtitle or caption timing, animation timing, and output format. The API validates that structure, queues the job, resolves any remote assets, renders the final composition, and returns a status object until the video is ready.

That is why JSON-driven video is attractive for engineering teams:

It is versionable and diffable like the rest of your application logic.
It makes video templates reusable across many content variations.
It fits cleanly into backend jobs, queues, and webhook or polling workflows.
It removes manual export steps when the creative structure is mostly stable.

If you only need one bespoke launch video, a traditional editing tool may still be faster. If you need the same video system to react to changing data, JSON starts to win.

How to convert JSON to video

At a high level, the lifecycle is: build the JSON payload, submit the render job, poll status, then store or publish the result URL. That is the practical answer to "how do I convert JSON to video?": the JSON file or JSON object becomes the source for layout, timing, media, text, and output settings.

A reliable render flow keeps payload generation, submission, and polling separate.

In practice, the flow is:

Generate or retrieve the structured content your video needs.
Map that content into one Zvid payload object.
Send the payload to POST https://api.zvid.io/api/render/api-key.
Save the returned jobId, status, and any queue metadata.
Poll GET https://api.zvid.io/api/jobs/{id} until state is completed or failed.
Use result.url when the render completes.

You can start with a static payload checked into your repo, then move to dynamically generated JSON once the first render works. For example, an ecommerce app might inject product names, prices, image URLs, and destination format into the same template. A localization workflow might keep the layout fixed while changing headline copy, subtitle language, and voiceover files.

The Submit render job and Get render job status references are the key docs to keep open while you wire this up. If you want to make the workflow safer in production, the Get credit balance and Get user profile references are also useful checks before you submit large batches.

This is the first useful CTA for most readers: do not start with a huge pipeline. Start with one payload, one render job, and one completed output. Once that loop is stable, scaling is mostly an orchestration problem.

The anatomy of a Zvid payload

Zvid's public docs define the render body as an object with a required payload. Inside that payload, the main fields are name, resolution, duration, frameRate, outputFormat, backgroundColor, visuals, audios, and subtitle. Those JSON objects give you control over every aspect that matters in a template-driven render: element types, coordinates, media URLs, timing, and platform-ready output. The JSON Structure overview, ResolutionPreset reference, and Text Elements reference are the most important references for understanding that shape.

Below is a proof-friendly Zvid API payload that renders a short landscape explainer card. It uses SVG and TEXT elements only so the structure is easy to inspect and adapt.

{
  "name": "json-to-video-api-guide-demo",
  "resolution": "hd",
  "duration": 9,
  "frameRate": 30,
  "outputFormat": "mp4",
  "backgroundColor": "#08111f",
  "visuals": [
    {
      "type": "SVG",
      "width": 1280,
      "height": 720,
      "svg": ""
    },
    {
      "type": "SVG",
      "x": 258,
      "y": 360,
      "width": 372,
      "height": 454,
      "anchor": "center-center",
      "track": 2,
      "enterBegin": 0.2,
      "enterEnd": 0.9,
      "enterAnimation": "smoothleft",
      "exitBegin": 8.1,
      "exitEnd": 8.7,
      "exitAnimation": "fade",
      "svg": ""
    },
    {
      "type": "TEXT",
      "x": 850,
      "y": 142,
      "width": 520,
      "anchor": "center-center",
      "track": 6,
      "enterBegin": 0.5,
      "enterEnd": 1.1,
      "enterAnimation": "fade",
      "exitBegin": 8,
      "exitEnd": 8.6,
      "exitAnimation": "fade",
      "html": "STRUCTURED VIDEO WORKFLOW"
    },
    {
      "type": "TEXT",
      "x": 850,
      "y": 258,
      "width": 520,
      "anchor": "center-center",
      "track": 8,
      "enterBegin": 0.7,
      "enterEnd": 1.4,
      "enterAnimation": "fade",
      "exitBegin": 7.9,
      "exitEnd": 8.5,
      "exitAnimation": "fade",
      "html": "Send JSON. Track jobs. Render videos at scale."
    },
    {
      "type": "TEXT",
      "x": 850,
      "y": 426,
      "width": 520,
      "anchor": "center-center",
      "track": 8,
      "enterBegin": 1,
      "enterEnd": 1.6,
      "enterAnimation": "fade",
      "exitBegin": 7.8,
      "exitEnd": 8.4,
      "exitAnimation": "fade",
      "html": "Define layout, timing, media, and output in JSON, then let the API queue and render the final video."
    },
    {
      "type": "TEXT",
      "x": 850,
      "y": 556,
      "width": 360,
      "anchor": "center-center",
      "track": 9,
      "enterBegin": 1.2,
      "enterEnd": 1.8,
      "enterAnimation": "fade",
      "exitBegin": 7.7,
      "exitEnd": 8.3,
      "exitAnimation": "fade",
      "html": "Start with one render job"
    },
    {
      "type": "TEXT",
      "x": 640,
      "y": 654,
      "width": 1080,
      "anchor": "center-center",
      "track": 4,
      "enterBegin": 1.4,
      "enterEnd": 2,
      "enterAnimation": "fade",
      "exitBegin": 7.6,
      "exitEnd": 8.2,
      "exitAnimation": "fade",
      "html": "A small payload example is enough to prove the render loop before you scale it."
    }
  ]
}

A payload stays useful when each field has a stable responsibility in the render.

The point of this example is not the design itself. The point is the shape: one object describes the video in a way your backend can generate repeatedly.

For image-heavy workflows, the Image Elements reference explains remote image handling, while the Text Elements reference covers the safe text and HTML options most teams use for headlines, labels, and CTAs.

A practical API request flow

Once you understand the payload, the rest of the system is normal API engineering.

Start by verifying auth:

curl -X GET https://api.zvid.io/api/user/profile \
  -H "x-api-key: YOUR_API_KEY"

Then check credits:

curl -X GET https://api.zvid.io/api/credits/balance \
  -H "x-api-key: YOUR_API_KEY"

Then submit a render request:

{
  "payload": {
    "name": "json-to-video-api-guide-demo",
    "resolution": "hd",
    "duration": 9,
    "frameRate": 30,
    "outputFormat": "mp4",
    "backgroundColor": "#08111f",
    "visuals": [
      {
        "type": "TEXT",
        "text": "Hello from Zvid",
        "x": 640,
        "y": 360,
        "anchor": "center-center",
        "style": {
          "fontSize": 54,
          "color": "#ffffff",
          "textAlign": "center"
        }
      }
    ]
  }
}

Poll until the job finishes:

curl -X GET https://api.zvid.io/api/jobs/$JOB_ID \
  -H "x-api-key: YOUR_API_KEY"

The Getting Started guide shows the same sequence with example responses. In production, the important discipline is to store the returned jobId, track status transitions, and only treat the video as complete when the jobs endpoint returns a finished result.

This is where the middle CTA makes sense: if you are still evaluating vendors or architecture, do not optimize for every edge case up front. Send one render, inspect the output, and confirm the API model fits how your product already stores data.

Video templates, animation, and dynamic output

A JSON to video workflow works best when the template is treated as a system contract. The JSON can hold fixed design rules, dynamic fields, or both. Fixed rules might include frame rate, resolution, brand colors, text styles, and animation timing. Dynamic fields might include headline text, image URLs, subtitle files, product details, prices, CTAs, and output format.

This is different from asking an AI video generator to interpret a loose text prompt. With structured JSON, the application can programmatically generate hundreds of videos while keeping the same layout and brand rules. You can still use AI-generated copy, images, or voiceovers upstream, but the render payload should stay explicit enough that the final video is predictable.

For a scalable pipeline, keep three layers separate:

Content data: the product, campaign, customer, or locale fields.
Template rules: the scene layout, text animation, element types, and fallback behavior.
Render orchestration: the API call, queue handling, retries, and final video URL storage.

Manual video tools vs JSON-driven rendering

Most teams should not think of JSON rendering as a replacement for all creative tools. It is a replacement for repeated manual export work when the video structure is stable.

Manual editors are better when every video needs hands-on creative changes.
A JSON to video API is better when the same structure repeats across many variants.
Manual editors optimize for one timeline at a time.
JSON-driven rendering optimizes for systems that can generate many timelines safely.

JSON rendering is strongest when the structure repeats and the inputs change.

If your use case is catalog automation, localization, campaign fan-out, onboarding videos, or personalized clips, the same template logic can keep paying off. That is why high-volume and feed-driven use cases often move toward structured rendering instead of more manual editing.

No-code integrations and JSON2Video alternatives

Some teams call a JSON to video API directly from a backend service. Others connect the same video automation workflow through no-code or low-code tools such as n8n, Zapier, Make, Shopify exports, CRM triggers, or scheduled spreadsheet jobs. The integration pattern is the same: collect structured data, generate the JSON payload, send the render request, and route the completed video file to the next system.

You will also see tools and category terms such as JSON2Video, video editing API, dynamic video, and programmatic video creation API in this market. The useful comparison is not only feature count. Ask whether the platform gives you enough control over templates, output formats, media handling, watermarks, API key authentication, job status, and repeatable rendering without manual editing.

For Zvid, the fit is structured video rendering through a hosted API. It is not positioned here as a prompt-only text-to-video model such as Sora, Veo, or Seedance, and it is not a hosting-only video API. It is for teams that want application data to become on-brand videos through explicit JSON payloads.

Common mistakes

The most common mistake is treating the JSON payload as a one-off export artifact instead of a reusable system contract.

Other mistakes show up repeatedly:

Mixing business data cleanup with scene layout logic in the same step
Hard-coding visual values that should come from reusable template rules
Skipping credit or auth checks before large submissions
Ignoring job-state tracking and assuming a successful submit means a finished render
Designing templates that only work for one headline length, one locale, or one media shape
Treating every provider as interchangeable without checking template control, integration needs, or output requirements

Another common failure is overfitting the first demo. A payload can look fine with one short headline and then break once real inputs are longer, translated, or missing optional media. That is why repeatability matters more than getting one perfect screenshot.

When to use Zvid

Use Zvid when you want a hosted API that turns structured video definitions into repeatable render jobs without building your own rendering pipeline.

Zvid is a strong fit when you need:

Programmatic video generation from structured app data
One template system reused across many outputs
Public API endpoints for auth checks, render submission, and job polling
Support for timed text, SVG, images, videos, audio, and subtitle-driven workflows
A scalable way to generate videos from JSON without manual editing for each variation

One structured video system can support many teams once the render loop is stable.

If you only need occasional handcrafted exports, the API model may be unnecessary. If you already have structured content and want the output video to be just another system-generated asset, it becomes much more useful.

The right next step is simple: build one small payload, render one finished video, and then decide whether your workflow needs more templates, more variations, or more orchestration around the same API core.

FAQs

Is a JSON to video API only for high-volume rendering?

No. High volume is one use case, but the same model is useful even for smaller systems when you want predictable, repeatable output from structured content.

How do I convert JSON to video?

Create a JSON payload that describes the video, send it to a render endpoint, save the returned job ID, and poll the job until the API returns a completed video URL. In Zvid, that means sending a payload to the render endpoint and tracking the job status.

Do I need to generate every field dynamically?

Not at all. Most teams keep a mostly fixed template and only inject the fields that change, such as title, subtitle, CTA, product image, locale, or destination format.

Can I render multiple videos from different JSON inputs?

Yes. Use the same template rules, generate one JSON object per variation, and submit one render job for each output. That is how teams generate videos automatically for product catalogs, localized campaigns, onboarding flows, and personalized clips.

Can I start with text and simple graphics before I add remote media?

Yes. That is often the safest way to prove the payload model first. Then you can expand into remote images, video clips, audio, or subtitles as the use case gets more complex.

Can I connect a JSON to video workflow to n8n, Zapier, or Shopify?

Yes, as long as the integration can prepare structured data and make authenticated API requests. Many teams use no-code tools for triggers and routing, while keeping template logic and render validation in application code.

What should I save from each render request?

Save the payload version, the returned jobId, the current job state, and the final output URL once the job completes. That gives you enough information to debug, retry, or regenerate later.

If your product already thinks in structured inputs, a JSON to video API is usually the cleanest path to repeatable rendering. Start with one Zvid payload, one render job, and one completed output, then expand only after that loop feels reliable.