Meta's Video Generation API: What Is Actually Callable

What is callable today

Meta has not published a developer API for video generation, as of the check on 2026-08-09. Movie Gen and related models exist, but the systems described on that page ship into consumer products, not into an endpoint a developer can call. No API key, no SDK, no request schema, no rate limit table, no pricing page for programmatic access — none of it exists in the record.

That absence sets this piece apart from most articles carrying "API" in the title. It is not a walkthrough of authentication, request bodies, or response formats, because there is nothing at that level to walk through. Meta's Movie Gen sits in the generative-model-api category of a tool inventory built from vendor documentation, alongside vendors that do publish an endpoint, a key, and a bill. For this one vendor, the documentation describes a demo, not an interface. A developer who searches "meta ai video generation api," "meta ai api for video generation," or "meta ai video generator api" today lands on marketing pages and blog posts about the underlying research, none of which contain a curl example, an SDK install command, or a token to paste into an environment variable.

The distinction that matters for infrastructure planning is between a model existing and a model being callable. Meta has shown Movie Gen output in public posts and product demos, and the underlying research has been described in enough detail to be discussed by name. Whether that output can be requested programmatically, on a schedule, at a fixed cost, for a pipeline that runs unattended, is a separate question, and the record answers it: no. A model that only runs inside Meta's own consumer apps cannot sit in a render queue next to ffmpeg or a paid generation service, because there is no request format to queue.

This also explains why the article the original title implied cannot be written. A tutorial needs an endpoint to call, a response to parse, and an error to catch. None of those three things exist for Movie Gen today, so the only accurate article is a record of the gap itself, dated, with a source, rather than a set of instructions for a call that cannot be made.

What the vendor's own page says

Meta's own blog post frames Movie Gen as a set of foundation models behind product features, not as a service with a developer-facing contract. The page describes research results and ties the capability to consumer surfaces inside Meta's own apps rather than to an external API product that a third party could integrate. Checked 2026-08-09, the page contains no developer console link, no API reference, no terms-of-service page scoped to third-party callers, and no mention of request quotas or per-call pricing.

A typical vendor page for a callable generation API carries a recognisable set of parts: an endpoint URL, a list of accepted parameters, an authentication method, a rate limit, and a page describing what happens when a request fails. Meta's Movie Gen page carries none of those parts, because it was not written to document an API. It was written to describe a model and the product experiences built on top of it inside Meta's own surfaces. That is a different kind of document, aimed at a different reader: someone evaluating the underlying research or the consumer feature, not someone about to write an integration.

This is not a case of thin documentation for an API that otherwise exists. There is no partner program page for programmatic access, and no changelog entry announcing an API in beta. Compare that to a vendor that has shipped a real API but documents it poorly: that vendor still has an endpoint URL somewhere, even if the docs page describing it is short or out of date. Meta's page has neither an endpoint nor a stated promise of one arriving on a given date.

The gap is between "a model exists" and "a model is callable." Meta has demonstrated Movie Gen capability in public, repeatedly, across more than one product surface. It has not published anything a build script, a cron job, or a backend service could call, and the record checked on 2026-08-09 does not show that changing.

What that leaves for anyone who built on it

Nothing to migrate away from, because nothing was ever live for outside developers to build against. This matters for how the finding gets read: it is not a deprecation notice, not a sunset date, not a breaking-change announcement in a changelog. There is no endpoint that stops responding, no key that gets revoked, no SDK version that throws a 404 on the next release. Anyone who already shipped a pipeline calling a Meta video generation endpoint was calling something undocumented, unofficial, or misidentified, because the vendor never published a contract to build against in the first place.

The practical consequence falls on planning documents rather than on running code. A stack comparison, a vendor shortlist, an internal wiki page that lists "Meta Movie Gen" as an option alongside a paid video generation API needs a correction, not a migration ticket. Any cost model that assumed a per-call Meta price needs to drop that line entirely, since no priced plan exists in the vendor record to cite, and estimating one would mean inventing a number this article is not permitted to invent either. Any architecture diagram with a box for a Meta video endpoint needs that box removed until Meta publishes something to point it at, and any procurement checklist that asks a vendor for a Meta Movie Gen SLA is asking a question the vendor cannot answer, because Meta itself has not published one.

For a team running build-versus-buy evaluation, the useful move is to strike Meta from the current shortlist of callable video generation services and treat it as a distribution channel to watch rather than a dependency to plan around. That watch has no fixed check-in date in the record, because Meta has not published a roadmap item, a waitlist, or an announced beta to watch for. A reader coming back to this question in six months has one reliable move: reread the vendor page rather than reread this article, since the vendor page is the only place the answer can change.

What still renders on this benchmark

Four tools produced a working file lasting 30 s against the same TPL-30 benchmark, and Meta did not sit among them because it has no render call to invoke. The benchmark specifies 1920×1080 at 30 fps, 30 s, h264 + aac, three scenes (title, body, outro) composited from a fixed set of pre-rasterised text and image assets, run on the same arm64 Homebrew ffmpeg 8.0.1_4 machine for every tool.

Tool	Wall time	Output size	Output duration	Cost
ffmpeg 8.0.1	7.5 s	0.99 MB	30.000 s	$0
MoviePy 2.1.2	86.6 s	1.01 MB	30.000 s	$0
Remotion 4.0.507	18.2 s	1.50 MB	30.059 s	$0
Editframe 0.59.40	17.9 s	1.46 MB	30.080 s	$0

Sourcevideobycode verification runs, TPL-30 benchmark, measured 2026-08-09 and 2026-08-25

Sourcevideobycode verification runs(TPL-30 benchmark, measured 2026-08-09 and 2026-08-25)

None of these four are ranked here on wall time alone, because the wall-time figures do not measure the same span of work. FFmpeg's number is close to a pure encode: filter graph setup and a single-pass render of three scenes gated by enable expressions onto one canvas lasting 30 s, rather than three separate encodes stitched with a concat step. No browser opens, no bundler runs. Remotion's number and Editframe's number both include a browser launch (headless Chromium for Remotion, system Chrome driven through Playwright for Editframe), plus a webpack bundle or a Vite dev-server startup, plus capture of every one of 900 frames, before the encode itself even starts. Neither figure is a stand-in for "how long the encode takes"; both are the full invocation, start to finished file. MoviePy's number covers interpreter startup, module import, scene composition inside Python, and a streamed encode through the same system ffmpeg binary the ffmpeg run uses directly, with FFMPEG_BINARY pointed at that system copy so the bundled binary inside imageio-ffmpeg is bypassed.

Cost reads as $0 for ffmpeg, $0 for MoviePy, $0 for Remotion, and $0 for Editframe, because all four runs stayed inside a free or open-source tier: ffmpeg and MoviePy carry no license fee at all, Remotion's license is free for individuals and for-profit companies of three or fewer employees, and the Editframe run used its free CLI tier with no account, no API key, and no cloud endpoint involved. None of these four cost figures says anything about what a hosted render service, a paid Editframe plan at higher volume, or cloud compute for the open-source tools would cost at production scale.

The caption bar, accent rule, and three text layers came from the same pre-rasterised PNGs in every run, because the ffmpeg build on the measuring machine has no libfreetype compiled in and therefore no drawtext filter at all. That constraint keeps text-shaping time out of all four numbers equally, which is what makes the four times comparable in the first place, but it also means none of these runs measures how each tool performs when it draws type natively from a font file instead of compositing a flat image.

Editframe's encoding surface differs from the other three in a way worth flagging for anyone selecting on this table alone: its CLI exposes fps, scale, and codec selection, but no CRF, preset, or pixel-format flag, so the crf=20 and preset=medium settings used in the ffmpeg and MoviePy payloads cannot be matched on the Editframe run, and its output bitrate is whatever its browser-based WebCodecs encoder chose rather than a setting anyone specified.

How to check this yourself

Read Meta's own Movie Gen post before trusting any third-party summary of what it offers, including this one. The page to check is the ai.meta.com blog post, checked here on 2026-08-09. Look for four things on that page and any page it links to: a developer console or dashboard link, an API reference page, a pricing page scoped to programmatic calls, and a code sample showing a request against an endpoint. If none of those four turn up, the answer has not changed since this check, regardless of how the page's marketing language reads.

Comparison sites and tool-inventory pages are the wrong place to check this, because entries get copied between them without anyone re-reading the vendor source each time. A "Meta video API" row on a third-party comparison table may be inherited from an earlier draft of that table, from a press-release summary written when the models were announced, or from confusion with a different Meta product that does carry a public, documented API, such as the Graph API or the WhatsApp Business API — neither of which generates video, and neither of which should be cited as evidence that a Movie Gen API exists. Reading the vendor's own page directly, and checking the date stamped on that read, avoids inheriting someone else's stale row.

No single tool from the table above is the recommended replacement for a Meta video API that does not exist. ffmpeg, MoviePy, Remotion, and Editframe solve different problems (a template-fill pipeline built on filter expressions, a Python-native compositor, a React-based renderer, a browser-driven CLI), and the right pick depends on which of those problems the pipeline actually has, not on which one rendered TPL-30 fastest on one arm64 machine on a given day.

Do not build a pipeline around meta-movie-gen: the consumer product produces clips through the app, not through a callable endpoint, so any integration plan that assumes a request-response API against Meta breaks before the first call. The render tools measured in this article, including the ffmpeg and MoviePy paths that produced a working output on this machine, cover the same rendering job today without requiring a partnership or an undisclosed enterprise contract. Route text-to-video and templated-render work through one of the measured local tools instead, and revisit Meta only if the vendor publishes a documented developer API with public pricing and an access process, not a blog post describing consumer features.

What we didn't test

• Other AI video generation APIs, apart from the tools measured here, were not covered in this run; Meta was excluded because it has nothing to call.
• The render tools were not compared using native web-font shaping instead of pre-rasterised PNGs, since the ffmpeg build here lacks libfreetype.
• Cost at production scale, meaning many renders a month through paid or metered cloud tiers, was not measured; the figures above reflect one local render on a free tier.
• Rendering machines other than the Homebrew build used here were not tried, so the wall-time figures should not be read as portable to a different processor architecture or a cloud instance with different hardware.
• This record carries one snapshot date for the Meta vendor page and does not track later API announcements; a reader checking this later should reread the vendor page instead of treating the finding above as current.

Questions people ask