Render Once, Deliver Everywhere With a Make Router
One event should often land in several places — a rendered card that needs archiving, announcing, and recording. Render it once with Rendex, then let a Make Router fan the same output out to Drive, Slack, and Airtable in parallel, each branch with its own filter.
Last updated 2026-07-21
The Problem
A single render frequently has more than one home: the invoice PNG belongs in Drive and attached to the customer record; the release card should hit Slack and the press folder; the report goes to email and an archive. The clumsy way is to build a separate scenario per destination — each one re-rendering the same image — or to chain destinations in a line so a failure partway stops the rest. Both waste renders and make the flow brittle: three scenarios to maintain, three credits per event, and no clean way to say 'only Slack if it's urgent'.
The Solution
Make's Router is built for exactly this. One Rendex HTTP module renders the artifact a single time; the Router then splits the flow into parallel branches that each receive the same render output. Map the module's binary Data (or a hosted render-link URL) into a Google Drive upload on one branch, a Slack message on another, and an Airtable update on a third — all fed by the one render. Each branch carries its own optional filter, so you can gate a branch on a condition ('post to Slack only when amount > $1,000') without touching the others. One render, one scenario, many destinations — and if one branch's app hiccups, the others still deliver.
How the Workflow Runs
Trigger
Any Make trigger — a new order, a published post, a webhook — kicks the scenario off.
Rendex HTTP module
POST /v1/screenshot renders the artifact once and returns the binary (or a hosted link).
Router — parallel branches
A Make Router splits the flow so every branch receives the same render output.
Deliver everywhere
Drive upload, Slack post, and Airtable write all run from the one render — each with an optional filter.
Input → Rendered Output

Rendered by Rendex
What You Need
- A Rendex API key — the free tier includes 100 renders/month with no card required.
- A Make account on any plan (the Router and HTTP module ship on every plan).
- The destination modules you want, connected in Make — e.g. Google Drive, Slack, Airtable.
- A trigger that produces the data to render — an order, a record, a form, or a webhook.
What This Recipe Uses
Render once, branch after
The Router sits downstream of a single Rendex render, so every branch reuses the same output — one credit per event, not one per destination.
Parallel delivery
Drive upload, Slack post, and Airtable write all run from the one render. A hiccup on one branch doesn't block the others.
Per-branch filters
Each Router branch carries its own optional filter, so you can gate a destination on a condition ('Slack only if urgent') without a second scenario.
Binary or hosted URL per need
Map the binary Data into file uploads and attachments, or render a hosted /v1/render/link URL once for the branches (Slack, Airtable) that want a link.
Build It
# Build it as: trigger -> render -> Router -> N branches.
1. Trigger (form / record / webhook)
2. HTTP (HTTP > Make a request) -> Rendex render (body below)
3. Router (Flow Control > Router) -> add three routes:
Branch A Google Drive > Upload a file
File = {{2.data}} (the binary PNG) name = card.png
Branch B Slack > Create a message
Text = "New card rendered" + a link/attachment
Branch C Airtable > Update a record
set an image/attachment field from the render
# Optional per-branch filter, e.g. on Branch B:
# {{1.amount}} Greater than 1000 -> Slack only for big orders// POST https://api.rendex.dev/v1/screenshot — Parse response = NO
{
"html": "<div style='width:800px;padding:56px;font-family:system-ui'><h1 style='color:#ea580c'>{{title}}</h1><p style='font-size:20px;color:#475569'>{{detail}}</p></div>",
"data": { "title": "{{1.title}}", "detail": "{{1.detail}}" },
"format": "png"
}
// Exactly ONE source field (html). The binary comes back as {{2.data}},
// which every file-upload / attachment branch maps directly.// POST https://api.rendex.dev/v1/render/link — Parse response = YES
{
"html": "<div style='width:800px;padding:56px;font-family:system-ui'><h1>{{title}}</h1></div>",
"data": { "title": "{{1.title}}" },
"format": "png"
}
// Response: { "url": "https://.../render/....png" }. Render once here and
// every branch maps {{2.url}} — a hosted URL Slack and Airtable accept
// without uploading a file. (Drive/email branches can still upload it too.)# On any Router branch, add a filter so it runs conditionally:
# Label: "Urgent only"
# Condition: {{1.priority}} Equal to "high"
#
# Branches without a filter always run. Branches with a filter run only
# when it passes — so broadcast + conditional delivery live in one scenario.100 free API calls/month — no credit card required. Get your API key and start building.
Reach for this whenever one event fans out to several homes — archive plus announce plus record. The trap people fall into is rendering the same image once per destination, either as separate scenarios or by re-calling the render on each branch; that's three credits for one artifact and three things to keep in sync. The Router fixes the shape: render first, then branch. Because the branches all sit downstream of the single HTTP module, each one maps the same Data output — the binary into a Drive upload or an email attachment, a hosted render-link URL into a Slack message or an Airtable field. Per-branch filters make it conditional delivery, not just broadcast: a branch runs only when its filter passes, so 'Slack only if urgent' and 'Airtable always' coexist in one scenario. If a destination genuinely needs a URL rather than bytes (Slack, Airtable), render with /v1/render/link once for a hosted URL every branch can reuse, or keep /v1/screenshot binary for the file-upload branches — pick based on where most branches land. It's free-tier on the render side, and the Router is Make-native flow control on every plan, so you consolidate what used to be several scenarios into one that renders once and delivers everywhere.