Make.com Airtable Video Processing Automation in One API Call

You keep a content ops base in Airtable: raw uploads land in a row, someone downloads the file, watermarks or captions it by hand, then pastes a link back into the record. The obvious fix is a Make.com scenario, and the obvious way to build it is the one that breaks, because Make starts pulling the video file into the scenario itself.

Quick answer: Make.com Airtable video processing works as a four-module scenario: the Airtable Watch Records trigger fires on a new or changed row, an HTTP > Make a request module posts the video's URL to the FFmpeg Micro API (api.ffmpeg-micro.com) as a job, a poll or webhook step waits for that job to finish, and Airtable's Update Record module writes the finished output URL back to the same row. The video bytes never enter Make, so Make's file size and timeout limits stop mattering. Free tier at ffmpeg-micro.com.

Conventional wisdom says video is too heavy for a no-code tool, and most Make scenarios prove it. The first build downloads the Airtable attachment, holds a few hundred megabytes in a bundle, and either dies on a data transfer limit or times out waiting on an encode. But the problem isn't the file size, and it isn't Make's plan tier. It's that the file is in Make at all. Once you treat the scenario as a message bus that passes URLs and job IDs, a 2 GB source video costs the same in Make as a 20 KB JSON payload.

The Airtable base setup that keeps the scenario from looping

Your base needs three fields before you touch Make: a URL or attachment field for the raw video, a single-select Status field, and a URL field for the processed output. The Status field is the part people skip, and it's what stops the scenario from triggering itself.

Make's Airtable Watch Records trigger usually watches a "Last Modified Time" field. Your last module updates the record. That update changes the last-modified time, the trigger fires again on the same row, and you've built an infinite loop that burns operations until you notice. The fix is to watch a filtered view instead: create a view with the condition Status is Queued, point Watch Records at that view, and have the final Update Record module set Status to Done along with the output URL. A row leaves the view the moment it's processed, so it can't come back.

One more Airtable detail that costs people an afternoon: Airtable attachment URLs expire about two hours after they're generated, a change Airtable shipped in late 2022. If your scenario grabs an attachment URL, sits in a queue, and hands that URL to a processing API 3 hours later, the download 403s. For anything queued, store a durable link in a plain URL field (S3, Cloudflare R2, Google Drive direct link, Vercel Blob) and pass that instead.

Build the scenario: Airtable trigger to output URL

The scenario is four modules, and only the middle two do real work. Set the schedule on the trigger first, because polling interval is where cost and latency get decided: Make's minimum interval is 1 minute on paid plans and 15 minutes on the free plan.

1. Airtable > Watch Records

Add the Airtable connection, pick your base and table, then set Table view to the filtered Queued view described above. Set Trigger field to Created time if rows are only ever queued once, or Last modified time if operators re-queue rows by flipping Status back. Limit is fine at 2 for testing; raise it to 10 for production so a batch of five uploads clears in one run.

2. HTTP > Make a request (submit the job)

This module is the whole post. It sends a small JSON body naming the input URL and the operation you want, and it gets back a job ID. Nothing downloads, so Make's data transfer meter barely moves.

{
  "url": "https://api.ffmpeg-micro.com/v1/jobs",
  "method": "POST",
  "headers": [
    { "name": "Authorization", "value": "Bearer {{connection.apiKey}}" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "body_type": "raw",
  "content_type": "application/json",
  "parse_response": true,
  "data": {
    "operation": "watermark",
    "input_url": "{{1.fields.`Raw Video URL`}}",
    "watermark_url": "https://cdn.yourbrand.com/logo.png",
    "position": "bottom-right",
    "opacity": 0.8
  }
}

Two settings in that module matter more than the body. Turn Parse response on, or you'll be running parseJSON() over a raw string in every downstream mapping. And set Timeout low, 10 seconds is plenty, because you're submitting a job, not waiting for an encode. The exact operation names and option keys per job live in the FFmpeg Micro docs; the envelope stays the same for captioning, resizing, audio extraction, and composition, which is what makes one HTTP module cover every video step in the base. Swap "operation": "watermark" for a caption job and the rest of the scenario doesn't change.

3. Wait for the job: sleep-and-poll, or a webhook

Two patterns work here, and the right one depends on how long your clips are. Sleep-and-poll is simpler: add Tools > Sleep for 30 seconds, then a second HTTP module doing GET https://api.ffmpeg-micro.com/v1/jobs/{{2.data.id}}, then a Router with a filter on {{3.data.status}} equal to completed. Make's Sleep module caps at 300 seconds per call, so a 4-minute encode needs the sleep inside a repeater rather than one long nap.

The webhook pattern is better for anything over a minute. Create a Custom webhook in a second scenario, pass its URL as webhook_url in the job body, and let scenario one end right after submitting. Scenario two wakes up when the job is done and does the write-back. This also sidesteps Make's 40-minute scenario execution limit, which a batch of long renders will hit if everything waits in one run.

4. Airtable > Update Record

Map Record ID from the trigger module ({{1.id}}), then set Processed Video URL to the output URL from the job status response and Status to Done. If you want the file living in Airtable rather than linked, map the same URL into an attachment field: Airtable fetches the file server-side, so Make still never touches the bytes.

The FFmpeg command vs the one API call

Everything above replaces a command you could run locally, and it's worth seeing both. A bottom-right logo at 15% of the video width, scaled for any input resolution, looks like this in FFmpeg:

ffmpeg -i raw.mp4 -i logo.png -filter_complex \
  "[1][0]scale2ref=w=iw*0.15:h=ow/mdar[wm][vid];\
   [vid][wm]overlay=W-w-24:H-h-24:format=auto" \
  -c:v libx264 -crf 23 -preset medium -c:a copy out.mp4

That command is correct and free. What it costs you is everywhere it has to live.

A faceless-channel operator watermarking 200 clips a night by hand is where this stops being a preference. Two hundred manual downloads, drags, and re-uploads is roughly a full workday; the same 200 rows through the scenario above is 800 Make operations and no human in the loop. For the watermark case, the video watermarking API walkthrough covers position, opacity, and tiling options in more depth, and the Make.com file size post explains why the URL-passing pattern is the fix rather than an upgrade.

Pitfalls that show up on real content ops bases

Most scenarios that fail in week two fail for one of a handful of reasons, none about video.

When a Make scenario is the wrong place for this

A Make scenario is the wrong tool when the trigger isn't a record change. If videos arrive by the thousand in a bucket, a queue consumer in code calling the API directly is cheaper and less fragile than paying per operation to poll Airtable. If a human needs to approve each output before it ships, keep Make for the processing step but do the review in Airtable itself with an interface, not with more modules.

And if what you actually need is a designer-driven template with animated text layers and brand kits, that's a template-editor product, not a media processing API. FFmpeg Micro does the deterministic work: transcode, caption, watermark, compose, extract. It doesn't render After Effects compositions.

FAQ

Can Make.com process video files without hitting its file size limit?

Make.com can process video of any size as long as the file itself never enters the scenario. Pass the video's URL to a processing API in an HTTP module and map the returned output URL forward, and Make only ever handles small JSON payloads. Downloading the file into a Make bundle is what triggers data transfer and size errors.

How do I trigger video processing when an Airtable record changes?

Use Make's Airtable Watch Records trigger pointed at a filtered view (for example, Status is Queued), then chain an HTTP module that submits the video URL as a processing job. Watching a filtered view rather than the whole table prevents the write-back from re-triggering the same row.

Should I poll for the job or use a webhook?

Webhooks are the better default for clips longer than about a minute, because Make's Sleep module caps at 300 seconds and the scenario execution limit is 40 minutes. Polling with a Sleep plus a status GET is fine for short clips and easier to debug while building.

Is this different from a native Airtable automation?

A native Airtable automation runs inside Airtable with a scripting step and no visual retries, while a Make scenario gives you routers, error handlers, and a filtered-view trigger you can reason about. Both can call the same API; Make is the better fit once the workflow has branches or needs to touch tools outside Airtable.

What does it cost to run video jobs from Make?

Pricing is usage-based per job with a free tier to start, so a base doing a handful of watermarks a day stays inside the free allowance while you test. Make bills separately per operation, and the scenario above is four operations per video.

If your Airtable base is already the queue, the only piece missing is the worker. Grab an API key on the free tier, drop it into one HTTP module, and let the row that used to wait for a person write its own output URL back. The UGC video workflow page has the same pattern applied to creator intake if that's the base you're building.