Zapier video processing can't encode. Send it to a video API

You have a Zap that receives a video and you need it smaller, captioned, resized, or converted before the next step fires. Zapier's directory has thousands of integrations and not one of them runs an encoder. The standard advice is "Zapier can't do video," which is half right and hides the part that actually breaks your workflow.

Quick answer: Zapier video processing works by orchestration, not encoding. Zapier has no FFmpeg step, caps file downloads at roughly 120 MB, and gives each action step 30 seconds to finish, so the Zap should send a video URL to an external video API and collect the finished file afterward rather than pushing bytes through Zapier itself. The DIY route is running FFmpeg on your own server behind an HTTP endpoint a Zap can call. FFmpeg Micro does that step as one API call with no servers to run and a free tier to test it.

What Zapier handles on its own, and what it never will

Conventional wisdom says the blocker is the missing FFmpeg step. That's partly true. Zapier will never ship an encoder, because Zapier is a request router with a 30-second budget per action and a video encode is a long-running compute job. But the thing that breaks real Zaps isn't the absent node. It's that Zapier tries to carry the file through itself.

Zapier moves files between steps using dehydration: the file contents don't travel inside the step payload, they're referenced and then downloaded when an app needs them. That works fine for a 2 MB PDF. A 400 MB screen recording hits a wall that has nothing to do with encoding.

On its own, a Zap can trigger on a new video in Google Drive or Dropbox, pass the file or its URL to another app, read whatever metadata the source app exposes, branch on duration or filename, and post the result to Slack, YouTube, or Airtable. What it cannot do is change a single byte inside the container. No transcode, no scale, no burned-in captions, no audio extraction, no concat.

The four limits that decide where the video step lives

Zapier publishes the numbers that matter here, and they're worth reading before you design the workflow instead of after a Zap dies at 2 a.m.

Zapier's own file documentation adds the practical version of the size cap: files over 100 MB may just time out, and the failure often surfaces as ENOSPC: no space left on device or a bare 400 rather than anything that says "too big." Code by Zapier closes the last escape hatch. Even with 512 MB of memory and 30 seconds, there's no FFmpeg binary in that sandbox and no way to install one.

Where you need an API: submit, wait, collect

The pattern that works in Zapier is the same one that works in n8n and Make: never route the bytes through the automation tool. Pass a URL in, get a URL back, and let a job API own the minutes in between. This is the Schwartz move. The fix isn't a faster Zap or a paid plan with a longer timeout, it's not doing the encode inside the Zap at all.

Get a real direct URL first

A direct download URL is the single most common point of failure in this workflow. Zapier's docs call out Google Drive sharing links, Slack file URLs, and cloud storage preview links as broken inputs, because they return an HTML page or demand authentication instead of serving the file. Use a signed S3, Cloudflare R2, or Google Cloud Storage URL, or whatever "direct download link" field the source app exposes.

Submit the job from Webhooks by Zapier

Webhooks by Zapier, set to Custom Request, is the step that hands the work off. The raw FFmpeg equivalent of a 1080p H.264 compress looks like this on a machine you maintain:

ffmpeg -i input.mp4 -vf scale=-2:1080 \
  -c:v libx264 -crf 23 -preset medium \
  -c:a aac -b:a 128k output.mp4

The same job as one HTTP call your Zap can make, with no binary to install and no box to keep patched:

curl -X POST https://api.ffmpeg-micro.com/v1/transcodes \
  -H "Authorization: Bearer $FFMPEG_MICRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": [{"url": "https://files.example.com/raw/clip.mp4"}],
    "outputFormat": "mp4",
    "preset": {"quality": "medium", "resolution": "1080p"}
  }'

In the Zapier step, that's a POST to https://api.ffmpeg-micro.com/v1/transcodes, the JSON body above with your trigger's file URL mapped into inputs, and an Authorization header holding your key. The response comes back immediately with a job id and status: "pending", which is the whole point. The Zap step finishes in well under 30 seconds because the render hasn't started yet. Full request and response shapes are in the FFmpeg Micro docs.

Collect the output without burning tasks

Two Zaps beat one long Zap here. Option one: add Delay by Zapier after the submit, then a second Webhooks step doing GET /v1/transcodes/{{id}}, then a Filter that only continues when status is completed. Option two, which costs less: have the job API call a Catch Hook URL when it's done and let that fire a second Zap. Zapier counts a task for each action step that runs successfully, while triggers and filters don't consume tasks, so a callback-driven second Zap is cheaper than a polling loop that re-checks a long render every minute. The reliability trade-offs of each approach are covered in webhooks for long-running video jobs.

Common pitfalls in Zapier video workflows

Most broken video Zaps fail for one of five reasons, and none of them are the encode itself.

When Zapier is the wrong driver for the video step

Zapier is a good fit when the video step is one hop in a business process: a UGC submission comes in, gets watermarked, lands in Airtable, pings Slack. It stops being a good fit in three cases.

High volume is the first. Zapier bills per task and caps a Zap at 100 steps, so rendering several hundred clips a night is cheaper driven from your own queue or from a workflow tool with native looping. Branching logic is the second. If the render shape depends on the result of three previous renders, that logic reads better in code than in a chain of Filters and Paths. The third is the one people hit hardest: if what you actually want is a timeline, templates, and a preview, you want a template-editor product, not an API and not Zapier. A job API gives you deterministic output from deterministic input, which is exactly what you want in a pipeline and exactly what you don't want when a human needs to nudge a text layer.

The same architecture carries over if you ever leave Zapier. n8n disabling the Execute Command node pushed its users to the identical submit-and-callback shape, and passing URLs instead of files is what keeps large media from blowing up any automation host.

FAQ

Can Zapier compress or convert a video file by itself?

Zapier cannot compress, convert, or re-encode video on its own. No built-in Zapier tool contains an encoder, and Code by Zapier has no FFmpeg binary available to it, so the actual transcode has to happen in an external service that a Zap calls over HTTP.

Does Zapier have an FFmpeg step?

Zapier has no FFmpeg step and no shell access. Code by Zapier runs JavaScript or Python in a sandbox with 512 MB of memory and no ability to install system binaries, so the only way to run FFmpeg from a Zap is to call an API that runs it for you.

How do I handle a video job that takes longer than 30 seconds in Zapier?

Split the job across steps instead of waiting inside one. A Zapier action step gets 30 seconds, so submit the video job in one step, get a job ID back immediately, then either add Delay by Zapier plus a status check or have the video API post the result to a Catch Hook that triggers a second Zap.

What's the largest video file a Zap can handle?

Zapier documents a 150 MB hard limit for hydrating files from connected apps and warns that files over 100 MB may time out. Keep the bytes out of Zapier entirely and pass a signed URL, and the file size stops mattering to the Zap.

Can I add captions or a watermark to a video from Zapier?

You can add captions or a watermark from a Zap by sending the video's URL to a video processing API and receiving the rendered file back. Zapier handles the trigger, the routing, and the delivery; the burn-in happens in the API, and FFmpeg Micro's blueprints cover the common versions of both jobs as preset one-click recipes.

If you want to test the pattern before rewiring anything, grab a key and run that single POST /v1/transcodes against one of your own files from a Webhooks by Zapier step. Sign up free and the free tier is enough to confirm the whole submit-and-collect loop works end to end.