Import one Make.com blueprint, paste your FFmpeg Micro API key, and you've got a webhook that handles 15 different FFmpeg operations — crop, trim, resize, combine, overlay text, extract audio, and more — served entirely from Make.com's cloud. No n8n, no FFmpeg install, no servers.

This is the n8n cloud automation ported to Make.com, with one architectural difference: the blueprint kicks off the transcode and responds immediately with a transcodeId. Your client polls the FFmpeg Micro API directly for completion. That keeps the webhook response fast (under Make's ~40 second sync-timeout) and works on Make.com's free tier.

What You'll Learn

• ✅ Make.com blueprint import — one JSON file, one webhook, 15 operations behind a router
• ✅ Custom webhook triggers + synchronous response — how Make.com's Webhook Response module returns JSON back to the HTTP caller
• ✅ Inline upload chain — presigned URL → binary PUT → confirm, all inside the Make flow using HTTP > Make a request
• ✅ Async kickoff pattern — why a Make webhook can't hold the connection open for a 2-minute transcode, and the simple 3-line polling loop that solves it
• ✅ Router with filter conditions — dispatching one webhook on an operation field to 15 different FFmpeg command bodies

The 15 Operations

How the blueprint is wired

Every invocation follows the same 7-step shape. Pre-router modules handle the upload (same for all ops); the router branches to the 15 per-operation transcode bodies.

1. Webhook trigger — receives { operation, fileUrl, filename, contentType, ... }
2. Set Variables — Bearer Token (single place to paste your API key)
3. HTTP > Make a request — GET the source fileUrl as binary
4. HTTP > POST /v1/upload/presigned-url
5. HTTP > PUT the binary to the presigned URL
6. HTTP > POST /v1/upload/confirm → returns the gs:// fileUrl
7. Router — 15 branches, each filtered on {{1.operation}} = "<op-name>", each running two modules:
   • POST /v1/transcodes with the op-specific body
   • Webhook Response returning { operation, transcodeId, status: "kicked-off" }

Why kick-off, not a polling loop?

Make.com's webhook synchronous response has a ~40-second timeout. A real transcode runs anywhere from a few seconds to several minutes — longer than Make will hold the HTTP connection open. If the scenario polled inside the blueprint, the caller would get a default Accepted before the Webhook Response module ever fired.

Instead, the blueprint does the upload and POSTs the transcode (well under 40s combined), then responds with a transcodeId. The caller polls GET /v1/transcodes/:id directly against api.ffmpeg-micro.com. That's the pattern baked into test-make-scenario.sh — ~30 lines of bash.

What You'll Need

Cost Breakdown

• • Make.com Free: 1 active scenario + 1,000 ops/month — each run burns 7-8 ops, so ~130 runs/month
• • FFmpeg Micro Free ($0/mo, 100 min): ~100 clips/month at ≤60s each
• • Total to start: $0 — no credit card on either side

Setup in 4 steps

1. Download + extract the zip above.
2. Import ffmpeg-make-cloud.json into Make.com (Scenarios → Create → Import blueprint).
3. Configure: create a webhook when the trigger opens, paste your API key into module #2, set scheduling to "Immediately as data arrives", toggle the scenario ON.
4. Test:

   export FFMPEG_MICRO_API_KEY=sk_live_xxx
   ./test-make-scenario.sh <your-webhook-url> extract-audio

Call it from anywhere

Once the scenario is live, any HTTP client works. Slack slash commands, Zapier, a cron job, a form submit — all of them boil down to:

curl -X POST <your-webhook-url> \
  -H "Content-Type: application/json" \
  -d '{
    "operation": "text-overlay",
    "fileUrl": "https://example.com/my-clip.mp4",
    "filename": "clip.mp4",
    "contentType": "video/mp4",
    "text": "Hello from Make.com!"
  }'

# → { "operation": "text-overlay", "transcodeId": "…", "status": "kicked-off" }

Differences from the n8n version

If you're coming from /training/ffmpeg-n8n-cloud — same pipeline, a few deliberate simplifications to fit Make.com's model:

• • Caller supplies contentType — no more JavaScript MIME sniffer (Make has no native JS runtime)
• • No sub-scenarios — n8n's Upload File / Wait for Transcode child workflows are inlined, so everything lives in one blueprint (works on Make free tier, 1 active scenario max)
• • Async kickoff — n8n holds the HTTP connection open while polling; Make can't, so the caller polls instead

Related training

• • n8n cloud version — same 15 ops, synchronous polling inside the workflow (works because n8n's webhook timeout is longer)
• • Make 100 shorts in under a minute — parallel bash pipeline driven by a CSV
• • Watermark a video — single-op bash pipeline using the same upload chain

Related endpoints

See the FFmpeg API documentation for the full reference. The endpoints this blueprint uses:

• • POST /v1/upload/presigned-url + POST /v1/upload/confirm — direct-to-GCS uploads
• • POST /v1/transcodes — submit the FFmpeg job
• • GET /v1/transcodes/:id — poll until completed (done by the caller, not Make)
• • GET /v1/transcodes/:id/download — signed MP4 URL