DEV Community: Renderly.Video

One JSON template, 500 unique videos: name-binding vs {{ mustache }}

Renderly.Video — Wed, 05 Aug 2026 11:22:36 +0000

You have 500 property listings and someone wants a walkthrough video for each one. You're not opening an editor 500 times.

The shape of the answer is obvious: one template, 500 rows of data, one render per row. The part that's actually interesting is how a template binds a variable to a layer, because the first thing everyone reaches for ({{ price }} string substitution) falls apart the moment one of your variables is a 40 MB mp4.

Node.js below, with the raw HTTP shown so it ports anywhere.

What actually comes out

Mechanics in a second. First, a real render, because "template-based video" is a phrase that could mean anything. This is the real-estate-penthouse template from the catalog: 31 seconds, six scenes, 1920x1080. Opening card and closing card:

Every string you can read in either frame came from a three-key payload:

{
  "listing_address": "1200 Highline Avenue",
  "city_location": "Belltown, Seattle",
  "price": "$4,250,000"
}

That is the entire dynamic surface of a 62-overlay template. The typography, the amber accent, the Ken Burns motion, the beds/baths/sq-ft panel, the closing CTA: all locked. Point those three keys at a row of an MLS export and you get one video per listing.

Full 31-second render on the template page.

The mechanic

Any overlay carrying isDynamic: true becomes a named variable. The overlay's name is the key. At render time the engine deep-clones the template, walks the overlays, and for each dynamic overlay whose name appears in your replacements object, swaps a type-appropriate field:

text and shape layers → the content field is replaced
image, video, and sound layers → the src field is replaced

That per-type rule is the whole trick, and it's the thing token substitution can't express. Here's a trimmed slice of a real template:

{
  "durationInFrames": 1620,
  "fps": 30,
  "width": 1920,
  "height": 1080,
  "replacements": {
    "headline": "1428 Maple Grove\nLane",
    "price": "$1,250,000",
    "photo_exterior": "https://cdn.example.com/1428-exterior.jpg",
    "clip_tour": "https://cdn.example.com/1428-tour.mp4"
  },
  "overlays": [
    { "type": "text",  "name": "headline",       "content": "1428 Maple Grove\nLane", "isDynamic": true },
    { "type": "text",  "name": "price",          "content": "$1,250,000",             "isDynamic": true },
    { "type": "image", "name": "photo_exterior", "src": "https://...jpg",             "isDynamic": true },
    { "type": "video", "name": "clip_tour",      "src": "https://...mp4",             "isDynamic": true },
    { "type": "text",  "content": "Just Listed", "isDynamic": false }
  ]
}

Two things to notice.

The replacements block at the top holds defaults. Your render request sends its own replacements, which merge over these, request wins. Anything you omit keeps the default, so a partial payload still renders instead of failing. After the merge, the replacements block is stripped from the props handed to the renderer.

The last overlay has isDynamic: false. "Just Listed" is now permanent brand framing: it renders identically on all 500 videos while everything above it changes. Locked layers are a feature, not an oversight.

One key fills every layer that claims it

Go back to the demo above. price renders twice: small and grey under "OFFERED AT" in the opening card, then as the hero line in the closing card. listing_address renders twice as well, and city_location three times.

The binding is name to every matching layer, not name to one layer. That penthouse template carries seven overlays with isDynamic: true and only three distinct names between them:

["listing_address", "city_location", "price"]  // 3 keys
//        x2                x3          x2     // across 7 overlays, 6 scenes

Which is why you never think about scene structure when you build a payload. You describe the listing once. The template decides where the address appears, how often, and in what treatment. Rename a key and you break every layer bound to it at once, so treat those names as an interface, not a label.

Worth being precise about one thing before the next section: the penthouse template exposes text only. Its three variables are all text overlays, with the photography baked in. The real-estate-listing template used in the snippets below exposes eight variables including five image slots and a video slot, and that's the one the next argument is about. Same engine, very different amount of surface area. How much a template exposes is the template author's call, which is why reading variables off the API beats assuming.

Why not `{{ mustache }}`

Three reasons, and the third is the one that actually decides it.

Accidental matches. A token scanner walks text looking for delimiters. It will happily rewrite {{ price }} inside a caption, an alt text, or a user-supplied string you never meant to touch. A named binding maps to exactly one layer, by id, before any text is read.

No escaping problem. You're never parsing user content for delimiters, so there's no delimiter to escape, and no "what if the address literally contains braces" edge case.

Binary media. This is the killer:

// Token substitution is fine here.
caption.replace("{{ price }}", "$1,250,000");

// Now do the same for a 40 MB mp4.
timeline.replace("{{ clip_tour }}", /* ...what, exactly? */);

You cannot string-interpolate a video file into a placeholder. You can point a video layer's src at a different URL. Name-binding treats text and media identically, one key to one layer to one field, which means the same mechanism that swaps a headline swaps a walkthrough clip. Token syntax needs a second, different mechanism for media, and now you have two systems.

Don't guess the variable names

This is the bit I'd have wanted on day one. You don't read the template JSON to learn its interface. You ask for it:

curl https://renderly.video/api/v1/templates \
  -H "Authorization: Bearer $RENDERLY_API_KEY"

Each template comes back with its variables (the names of every isDynamic overlay) and its defaults. So discovery is programmatic:

const res = await fetch("https://renderly.video/api/v1/templates", {
  headers: { Authorization: `Bearer ${process.env.RENDERLY_API_KEY}` },
});
const { data } = await res.json();

const tpl = data.find(t => t.id === "real-estate-listing");
console.log(tpl.variables);
// ["photo_exterior", "headline", "price", "clip_tour",
//  "photo_living", "photo_open", "photo_kitchen", "photo_dining"]

Eight variables on that one: two text fields, five image slots, one video slot. Validate your column mapping against that array at startup and you turn a silent "why is scene 4 still the default photo" into a loud error.

Render one

One POST per row. Template id, that row's replacements, and optionally a one-off webhook URL:

curl -X POST https://renderly.video/api/v1/renders \
  -H "Authorization: Bearer $RENDERLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "templateId": "real-estate-listing",
    "replacements": {
      "headline": "1428 Maple Grove\nLane",
      "price": "$1,250,000",
      "photo_exterior": "https://cdn.example.com/1428-exterior.jpg",
      "clip_tour": "https://cdn.example.com/1428-tour.mp4"
    },
    "webhookUrl": "https://yourapp.com/webhooks/renderly"
  }'

You get a job back immediately:

{
  "success": true,
  "data": {
    "jobId": "cmd8x2f9k0001qp3v7h2n4x8t",
    "status": "PROCESSING",
    "mode": "template",
    "creditsUsed": 1,
    "estimatedDurationMinutes": 0.9
  }
}

Status values are uppercase: PENDING, PROCESSING, COMPLETED, FAILED. If you write if (status === "pending") you will wait forever, which is a five-minute bug that feels like a thirty-minute one.

mode echoes which of the three request shapes you used: template (a public template id), project (one of your own saved projects), or direct (raw inputProps, no template at all). Send none of the three and you get a 400 telling you so. Send a template id that isn't public and you get a 403, not a 404, which is a useful distinction when you're debugging why your own draft template won't render.

Poll GET /api/v1/renders/:jobId if you must, but prefer the webhook. render.completed arrives with a download URL, render.failed arrives with a reason.

Two things worth knowing about the payload

Replacements can be flat. Any top-level key the endpoint doesn't recognize gets folded into replacements for you. These are equivalent:

{ templateId: "real-estate-listing", replacements: { price: "$1,250,000" } }
{ templateId: "real-estate-listing", price: "$1,250,000" }

Handy when you're piping a flat CSV row straight in. If a key appears in both places, the nested replacements object wins. I'd still use the explicit nested form in anything long-lived, because the flat form silently swallows typos: misspell templateId as templatedId and it becomes a replacement named templatedId instead of throwing.

\n in text content gives you a real line break. Look again at that default: "1428 Maple Grove\nLane". That's deliberate. A long address on a single line gets shrunk to fit the frame, and a 40-character street name renders at a size nobody can read on a phone. Break it yourself where it makes sense:

function addressForVideo(street) {
  const words = street.split(" ");
  if (words.length < 3) return street;
  const mid = Math.ceil(words.length / 2);
  return words.slice(0, mid).join(" ") + "\n" + words.slice(mid).join(" ");
}

Also worth knowing before you budget: credits are duration x rate x resolution multiplier, rounded up to the nearest 0.5. The multiplier is 1x at 1080p, 2x at 2K, 4x at 4K and above. So that 54-second listing costs 1 credit at 1080p and 4 at 4K, and a 12-second clip costs 0.5 rather than some fraction you can't reason about.

Render 500

Now it's just a loop, and the only real decision is concurrency. Don't await in a for loop over 500 rows unless you enjoy waiting:

const BATCH = 20;

async function renderListing(listing) {
  const res = await fetch("https://renderly.video/api/v1/renders", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.RENDERLY_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      templateId: "real-estate-listing",
      replacements: {
        headline: addressForVideo(listing.address),
        price: listing.priceFormatted,
        photo_exterior: listing.photos.exterior,
        photo_kitchen: listing.photos.kitchen,
        clip_tour: listing.tourClip,
      },
      webhookUrl: "https://yourapp.com/webhooks/renderly",
    }),
  });
  if (!res.ok) throw new Error(`${res.status} ${await res.text()}`);
  return res.json();
}

for (let i = 0; i < listings.length; i += BATCH) {
  const settled = await Promise.allSettled(
    listings.slice(i, i + BATCH).map(renderListing)
  );
  const failed = settled.filter(s => s.status === "rejected");
  if (failed.length) console.error(`batch ${i / BATCH}: ${failed.length} failed`);
}

Note the five keys against eight available variables. The three photo slots I left out keep their template defaults, which is exactly what you want when a listing only shipped two usable photos.

Retries, HMAC verification on the webhook callback, and what changes at 10,000 rows are their own topic. I wrote that one up separately: Generate 1,000+ personalized videos with a REST API.

When to skip all of this

If you're making one video, edit one video. The tagging work only pays off on repeatability: same structure, changing data, more than a handful of times. A launch film or a bespoke brand piece fails that test, and forcing it into a template is how you end up with a template that has forty variables and serves nobody.

The break-even is lower than it feels, though. A dozen videos already covers the cost of marking up the layers.

Wrap-up

The whole model is four lines: mark a layer isDynamic, give it a stable name, bind that name in replacements, and let the layer type decide whether content or src gets swapped. Because the binding is by name and not by scanning text, it works the same for a headline and a walkthrough clip, and it doesn't break when your data contains braces.

Full version with the cost breakdown and the spreadsheet and no-code paths: Dynamic Video Templates: Variable-Based Video Creation. Or grab a key at renderly.video and render one from the template above.

How are you handling media variables in your own templating layer? I'm curious whether anyone has made token syntax work cleanly for binary assets, because I couldn't.

Generate 1,000+ personalized videos with a REST API (Node.js)

Renderly.Video — Thu, 18 Jun 2026 02:40:43 +0000

Your platform has 5,000 products and someone wants a personalized demo video for each one. By tomorrow.

You're not booking a studio. You're writing a loop. This post is that loop: a batch pipeline that queues thousands of template-based renders, verifies webhook callbacks, retries the flaky ones, and doesn't fall over at scale. Node.js throughout, with Python equivalents noted inline.

I'll skip the marketing case. Template rendering runs about $0.10 to $0.50 per video at volume against $1,000 to $7,000 a minute for agency footage, so the ROI was never the blocker. Production capacity was. Let's build.

What you're building

Template-driven generation with a JSON replacements payload
Bulk processing for 1,000+ videos with batching and rate limits
Webhook callbacks with HMAC signature verification
Exponential-backoff retries and explicit error-code handling

Stack: Renderly (video API), Node.js, Promise.allSettled for concurrency, webhooks for completion. A queue like BullMQ on Redis helps once you're past ~10k, but you don't need it to start.

The API foundation

One endpoint, Bearer auth, JSON bodies. Base URL renderly.video/api/v1.

const RENDERLY_API_KEY = process.env.RENDERLY_API_KEY;
const API_BASE_URL = 'https://renderly.video/api/v1';

async function createRender(templateId, replacements) {
  const res = await fetch(`${API_BASE_URL}/renders`, {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${RENDERLY_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ templateId, replacements }),
  });
  if (!res.ok) {
    const err = await res.json();
    throw new Error(`API ${res.status}: ${err.message}`);
  }
  return res.json(); // { id, status: 'pending', ... }
}

The template system: `isDynamic`, not `{{ mustache }}`

Most video API tutorials show {{ variable }} placeholders. Renderly is overlay-based instead, and this is the thing that trips people up on their first try.

Each overlay element carries an isDynamic flag. When it's true, that overlay's content becomes a named variable. Your request sends a replacements object keyed by overlay name, and the renderer matches by name to swap the value in. It replaces content for text and shape overlays, and src for image, video, and audio.

{
  "overlays": [
    { "type": "text",  "name": "product_name",  "content": "Default", "isDynamic": true },
    { "type": "image", "name": "product_image", "src": "https://cdn.example.com/default.jpg", "isDynamic": true },
    { "type": "text",  "name": "price", "content": "$0.00", "isDynamic": true },
    { "type": "text",  "content": "Powered by Acme Co.", "isDynamic": false }
  ]
}

That last overlay (isDynamic: false) is the brand watermark. It stays identical across all 1,000 videos. Rendering one variation is a single call:

const job = await createRender('product-demo-v1', {
  product_name: 'Premium Noise-Canceling Headphones',
  product_image: 'https://cdn.example.com/headphones-sku-42.jpg',
  price: '$149',
});
// { id: 'job_xyz', status: 'pending' }

One template, unlimited variations, zero per-video setup.

Bulk generation: batch, don't blast

Naive for…await is the first mistake. It turns a 20-minute run into 3 hours. Naive Promise.all is the second: one rejection kills 999 good renders. Bounded batches of Promise.allSettled avoid both:

async function generateInBatches(items, templateId, batchSize = 50) {
  const results = { succeeded: [], failed: [] };

  for (let i = 0; i < items.length; i += batchSize) {
    const batch = items.slice(i, i + batchSize);
    console.log(`Batch ${i / batchSize + 1} — ${batch.length} videos`);

    const settled = await Promise.allSettled(
      batch.map(p => createRender(templateId, {
        product_name: p.name,
        product_image: p.imageUrl,
        price: p.price,
      }))
    );

    for (const r of settled) {
      if (r.status === 'fulfilled') results.succeeded.push(r.value);
      else results.failed.push({ reason: r.reason.message });
    }

    // breathe between batches to stay under rate limits
    if (i + batchSize < items.length) await new Promise(r => setTimeout(r, 2000));
  }
  return results;
}

Throughput is rarely the bottleneck. Hosted template APIs handle 10k to 100k+ renders a month. Your error strategy matters more than how fast you submit.

Tracking completion: webhooks over polling

Polling works for a handful of jobs. In production, register a webhook and let the API tell you when a render lands. Don't skip signature verification. It's one createHmac call standing between your endpoint and spoofed events:

import crypto from 'crypto';

app.post('/webhook/render-complete', express.json(), (req, res) => {
  const expected = 'sha256=' + crypto
    .createHmac('sha256', process.env.WEBHOOK_SECRET)
    .update(JSON.stringify(req.body))
    .digest('hex');

  if (req.headers['x-renderly-signature'] !== expected) {
    return res.status(401).json({ error: 'Invalid signature' });
  }

  const { jobId, status, outputUrl, error } = req.body;
  if (status === 'completed') console.log(`✅ ${jobId}: ${outputUrl}`);
  else if (status === 'failed') console.error(`❌ ${jobId}: ${error}`);

  res.json({ received: true });
});

The full script

Loads data, retries with exponential backoff, batches, reports:

// generate-bulk-videos.js
import 'dotenv/config';

const API = 'https://renderly.video/api/v1';
const KEY = process.env.RENDERLY_API_KEY;
const TEMPLATE_ID = 'product-demo-v1';
const BATCH_SIZE = 50;

async function createRender(replacements) {
  const res = await fetch(`${API}/renders`, {
    method: 'POST',
    headers: { Authorization: `Bearer ${KEY}`, 'Content-Type': 'application/json' },
    body: JSON.stringify({ templateId: TEMPLATE_ID, replacements }),
  });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json();
}

async function withRetry(replacements, attempt = 0) {
  try {
    return await createRender(replacements);
  } catch (err) {
    if (attempt >= 3) throw err;
    await new Promise(r => setTimeout(r, Math.min(1000 * 2 ** attempt, 30_000))); // 1s,2s,4s
    return withRetry(replacements, attempt + 1);
  }
}

async function run() {
  // swap for your real source: DB query, CSV, upstream API
  const products = Array.from({ length: 1000 }, (_, i) => ({
    name: `Product ${i + 1}`,
    imageUrl: `https://cdn.example.com/products/product-${i + 1}.jpg`,
    price: `$${(10 + i * 0.5).toFixed(2)}`,
  }));

  let succeeded = 0, failed = 0;
  for (let i = 0; i < products.length; i += BATCH_SIZE) {
    const batch = products.slice(i, i + BATCH_SIZE);
    const settled = await Promise.allSettled(
      batch.map(p => withRetry({ product_name: p.name, product_image: p.imageUrl, price: p.price }))
    );
    succeeded += settled.filter(r => r.status === 'fulfilled').length;
    failed += settled.filter(r => r.status === 'rejected').length;
    if (i + BATCH_SIZE < products.length) await new Promise(r => setTimeout(r, 2000));
  }
  console.log(`Done: ${succeeded} queued, ${failed} failed`);
}

run().catch(console.error);

Error codes worth handling explicitly

401 invalid or expired API key
402 credits exhausted. Check your balance before a big run, since it's a 402 and not a generic 500
404 template ID not found
429 rate limited, which the backoff above already handles

Realistic numbers (from production, not marketing copy)

Scale	Queue time	Render completion
100 videos	~2 min	~10-15 min
1,000 videos	~15-20 min	~1-2 hours
10,000 videos	~2-3 hours	~12-24 hours

Queueing is fast. Rendering happens server-side and concurrently, so wall-clock time tracks template complexity and resolution more than your submission speed. Lean templates (fewer overlays, compressed assets, shorter durations) are the single biggest throughput lever. If 10k jobs start hitting time limits, look at the template before you touch the code.

Three pitfalls that bite at scale

Sequential await instead of Promise.allSettled. This is the 20-minute run that quietly becomes a 3-hour one.
No retry tracking. Persist failed job IDs to a list or table for a second pass. Log-and-forget loses those renders for good.
Missing replacements defaults. An absent key falls back to the overlay's template default, so populate defaults in the template JSON.

Wrap-up

The pipeline above does 1,000 personalized videos in roughly 15 to 20 minutes of queue time, and it scales linearly. 10k is just more batches. Start with 10, confirm your template renders end-to-end, then turn up the volume.

The full version with the cost breakdown and the four production approaches lives here: How to Generate 1,000+ Personalized Videos with API Automation. Or grab an API key at renderly.video.

What's your current approach to bulk media generation? Queue-based, serverless fan-out, something else? Curious what's actually working for people.

DEV Community: Renderly.Video

One JSON template, 500 unique videos: name-binding vs {{ mustache }}

What actually comes out

The mechanic

One key fills every layer that claims it

Why not {{ mustache }}

Don't guess the variable names

Render one

Two things worth knowing about the payload

Render 500

When to skip all of this

Wrap-up

Generate 1,000+ personalized videos with a REST API (Node.js)

What you're building

The API foundation

The template system: isDynamic, not {{ mustache }}

Bulk generation: batch, don't blast

Tracking completion: webhooks over polling

The full script

Error codes worth handling explicitly

Realistic numbers (from production, not marketing copy)

Three pitfalls that bite at scale

Wrap-up

Why not `{{ mustache }}`

The template system: `isDynamic`, not `{{ mustache }}`