Render designed images and videos straight from your automations: three practical recipes for calling the JsonCut template API from n8n workflows and Make scenarios, with webhook triggers, polling vs. callbacks, idempotency keys and the 500-row bulk cap.
Why render visuals from a workflow engine?
Most automation platforms are great at moving data and terrible at producing files that look designed. Spreadsheets, CRM updates and chat notifications travel freely between n8n, Make and everything else — but the moment a workflow needs a branded image or a short video, someone opens a design tool by hand.
JsonCut closes that gap with a REST API. You design a visual once in Studio, publish it as a typed template, and from then on any workflow can render it with new inputs: a product headline, a price, a translated string, a photo. The result is a finished PNG, WebP or MP4 your automation can attach, upload or publish downstream.
This article walks through three recipes that treat JsonCut as just another HTTP service inside your existing tooling: a template render from an n8n HTTP Request node, a webhook-triggered variant renderer, and the same pattern in Make. All request and response examples come from the JsonCut API documentation and the project quickstart.
What you need before you start
| Requirement | Where it comes from | Notes |
|---|---|---|
| API base URL | https://api.jsoncut.com | V2 REST API, same base for all recipes |
| API key | Studio → Settings → API keys | Sent as X-API-Key header; keep it server-side only |
| Published template | Studio, then POST /api/v2/templates | Version-pinned project with a typed input contract |
| Input contract | GET /api/v2/templates/{id}/inputs | Field names, types, constraints, accepted MIME types |
| HTTP node or module | n8n HTTP Request node / Make HTTP request | Any tool that can send headers and a JSON body works |
One detail saves a lot of trial and error: never guess field names. The /inputs endpoint describes every required field, its type and its constraints — including which MIME types image or video inputs accept. Build your workflow payload against that contract, not against what the Studio canvas happens to show.
Recipe 1: Render a template from an n8n HTTP Request node
The n8n HTTP Request node makes REST calls to any API and supports methods like GET and POST, custom headers, and JSON bodies — either as fields or as raw JSON. It also lets you import an existing curl command, which is the fastest way to set it up from the JsonCut docs.
First, trigger the render:
POST /api/v2/templates/{template_id}/renders
X-API-Key: <your key>
Idempotency-Key: sku-1042-de
Content-Type: application/json
{
"values": {
"headline": "Available now",
"price": 79.9,
"productImage": "jsoncut-media://media_01J..."
},
"kind": "image",
"format": "webp",
"imageQuality": 92
}
The response is asynchronous and contains a render ID. Set kind to video with the appropriate format when your template is a video composition — the API surface is the same.
Second, collect the artifact with a follow-up GET request to /api/v2/renders/{render_id} to check status, then /api/v2/renders/{render_id}/artifact to download the file. The quickstart recommends signed webhooks over frequent polling for production, which the next recipe covers.
Two n8n specifics worth using: store the API key once as a Header Auth credential instead of pasting it into every node, and remember that the HTTP Request node can also be attached to an AI agent as a tool — an assistant can trigger a render conversationally while the credential stays in n8n.
Recipe 2: Webhook-triggered variant renders
The n8n Webhook node is a trigger: it exposes a URL that starts a workflow when an external service calls it. That turns JsonCut rendering into a small internal API — your app posts a product update, n8n renders the visual.
A minimal flow:
| Step | Node | What it does |
|---|---|---|
| 1 | Webhook trigger | Receives { "sku": "1042", "lang": "en", "headline": "...", "price": 79.9 } |
| 2 | Set node | Maps incoming fields to the template's input contract |
| 3 | HTTP Request | Posts to /renders with an Idempotency-Key built from sku + lang |
| 4 | HTTP Request or webhook handler | Waits for completion and forwards the artifact URL |
The Webhook node gives you separate test and production URLs — use the test URL with Listen for test event while building, and register the production URL once the workflow is active. It supports Basic, Header and JWT authentication for callers, and you choose when n8n responds: immediately with "workflow started", when the last node finishes, or via a dedicated Respond to Webhook node. For render requests, responding when the last node finishes lets you return the render ID (or even the finished artifact link) in one round trip. Keep payloads lean — the webhook maximum payload is 16 MB.
For completion events in the opposite direction, JsonCut can call you back: the API supports signed webhooks, so instead of polling /renders/{id} in a loop, your scenario can simply wait for the callback.
Recipe 3: The same flow in Make
Make users don't need a dedicated JsonCut app to get started. The platform's HTTP request capability lets you call any REST API from a scenario — Make's own developer documentation uses exactly this as the practice exercise: make a test HTTP call to your selected API before deciding whether to build something more structured.
The mapping is one-to-one with Recipe 1:
| JsonCut call | In your Make scenario |
|---|---|
POST /api/v2/templates/{id}/renders | HTTP request module, JSON body, X-API-Key header |
Idempotency-Key header | Set per scenario run from the item's natural key |
GET /api/v2/renders/{id} | Second HTTP request, or a webhook receiver scenario |
Bulk jobs (/bulk-renders) | One HTTP request with a JSON file or inline rows |
Two Make-specific options are worth knowing. If you later want a reusable connector instead of raw HTTP calls, Make supports building custom apps against any third-party API. And if AI agents are part of your stack, Make offers an MCP server (currently early access) that lets AI systems trigger your automation scenarios — a natural companion to JsonCut's own MCP interface for assistants that work directly against your media projects.
Polling vs. webhooks: picking a completion strategy
Renders are asynchronous — the API returns a render ID immediately and the file appears when the render finishes, passing through queued, rendering and terminal states (completed, failed or cancelled). Both completion strategies are valid:
| Strategy | How | Best for |
|---|---|---|
| Poll | Loop GET /api/v2/renders/{id} with a wait | Low-volume jobs, quick tests, debugging |
| Signed webhook | Register a callback URL, react to the event | Production, high volume, downstream chains |
The quickstart is explicit: for production, prefer signed webhooks over frequent polling. In n8n, a webhook receiver fits the same Webhook node you already use as a trigger; in Make, a dedicated scenario exposes an HTTPS endpoint.
Batches, idempotency and the 500-row cap
When a workflow should produce many variants at once, don't fan out hundreds of single renders. The bulk endpoint accepts JSON or CSV and validates every row before queueing:
POST /api/v2/templates/{template_id}/bulk-renders
X-API-Key: <your key>
{
"version": 4,
"items": [
{ "idempotencyKey": "sku-1042-de", "values": { "headline": "Jetzt erhältlich", "price": 79.9 } },
{ "idempotencyKey": "sku-1042-en", "values": { "headline": "Available now", "price": 79.9 } }
],
"output": { "kind": "image", "format": "png" }
}
Three rules make bulk jobs safe from a workflow:
| Rule | Why it matters in automation |
|---|---|
| JSON and CSV batches are capped at 500 rows | Chunk larger catalogs into multiple requests in your scenario |
| Each batch pins one immutable template version | A retried run renders the exact design you approved |
| Invalid rows are reported without blocking valid rows | One malformed input doesn't kill the job; resubmit only the failures |
Idempotency keys are the quiet hero here. If your workflow retries after a timeout and re-sends the same Idempotency-Key, you get one render instead of two — the difference between a clean retry and a duplicated asset library. Derive keys from stable business data (SKU plus language, campaign ID plus date), never from random IDs.
Security and operations checklist
| Check | Recommendation |
|---|---|
| API key storage | Server-side only — n8n credentials or Make connection settings, never frontend code |
| Webhook exposure | Require Header or JWT auth on inbound trigger URLs; use the test URL while building |
| Key rotation | Rotate in Studio → Settings → API keys; update the single credential object |
| Failure handling | Branch on failed/cancelled render states before touching downstream nodes |
| Batch hygiene | Stay under the 500-row cap and log per-row validation errors for resubmission |
FAQ
Do I need a dedicated JsonCut integration for n8n or Make?
No. Everything in this article is plain HTTP against https://api.jsoncut.com — headers plus a JSON body. Any node or module that can make a REST call works.
Can one workflow render both images and videos?
Yes. The same render endpoint takes a kind; image templates and video compositions differ in the values they need, which the /inputs endpoint spells out per template.
What happens if my scenario runs twice?
With a stable Idempotency-Key, the second run maps to the same render instead of creating a duplicate. Without one, you get two renders.
Sources
JsonCut API documentation – Templates and bulk rendering, https://jsoncut.com/docs/templates/, accessed 2026-10-11.
JsonCut project quickstart, https://jsoncut.com/docs/quickstart/, accessed 2026-10-11.
JsonCut documentation overview, https://jsoncut.com/docs/, accessed 2026-10-11.
n8n HTTP Request node documentation, https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest, accessed 2026-10-11.
n8n Webhook node documentation, https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook, accessed 2026-10-11.
Make Developer Hub, https://developers.make.com/, accessed 2026-10-11.
Make Custom Apps documentation, https://developers.make.com/custom-apps-documentation, accessed 2026-10-11.