What happened
Black Forest Labs' API documentation describes generating video with FLUX 3 Max on fal. It presents three modes: text-to-video, image-to-video, and keyframes-to-video. Each request uses a fal API key, and the documentation says requests and billing go through the user's fal account. The endpoints are queue-based: a request returns a status URL and a response URL. The client polls the status URL until the job is complete, then retrieves the result, where the video is available at video.url.
In text-to-video, a prompt describes the desired video. The example request also sets duration, resolution, and aspect ratio. In image-to-video, the prompt and an image URL define the generation, with the supplied image serving as the starting point; an optional end_image_url can specify the final frame. The API therefore supports both a text-only flow and a flow in which an application provides an existing visual asset as a compositional anchor.
In keyframes-to-video, a request can include up to 10 images, each assigned a frame_index. The output runs at 24 frames per second, so frame 72 corresponds to second three. Indices must be unique and no greater than duration multiplied by 24. A prompt describes motion between the keyframes. This makes the input a bounded timeline: an application can select particular stills and their positions rather than relying solely on a prose instruction to govern the full clip.
The documented duration options run from 5 to 20 seconds, with 5 seconds as the default. Resolution options are 720p, 1080p, 2K (1440p), and 4K (2160p); the documentation says 1080p and above are upscaled from 720p generation, and exact dimensions depend on aspect ratio. Available aspect ratios include auto, 21:9, 2:1, 16:9, 4:3, 1:1, 3:4, and 9:16. Auto uses 16:9 for text prompts and follows the first image otherwise.
Audio generation defaults to true. The reasoning level defaults to high, with low and high as the listed options; higher effort means slower generation. A seed can be provided, or the generation is random when none is supplied. The initial response can report IN_QUEUE, IN_PROGRESS, or COMPLETED, as well as a request ID, URLs for status and response, and a queue position. A client can also receive a cancellation URL, which gives an application a documented handle for a job that should no longer run.
What the archive adds
New Runtime's earlier coverage on October 22 described FLUX 3 Max as a latency-optimized, post-trained FLUX 3 Video variant. This documentation is a new fact on that known story: it makes the API's three input modes and operating controls explicit, rather than establishing a separate launch.
Trend signal
This supports generative media becoming application infrastructure: generation is exposed through a callable API with multiple input modes and adjustable output parameters. The documentation establishes the interface, not whether it is cheap, low-latency, or reliable at scale, so it only supports the pattern's product-boundary aspect.
Why it matters
For a product team, the three modes correspond to different control surfaces. Text prompts are the simplest interface for unconstrained generation; an initial image can anchor the opening frame; and keyframes let a workflow specify selected moments and ask the model to fill in motion between them. That lets teams test whether user-supplied visual references or storyboard-like inputs improve the fit of generated clips.
The queue workflow also matters architecturally. A product cannot assume that generation finishes within a synchronous request: it needs to retain the request identifier, poll for completion, and retrieve the output. The status model makes a job lifecycle visible to the application, while the cancellation URL offers a path to stop work that is no longer needed. Those details affect interface design: a user needs progress feedback, retry handling, and a place to return to completed output.
Duration, resolution, audio, and reasoning level create explicit choices for the user experience and for cost or latency experiments, although the documentation page does not quantify those trade-offs. The 4K option should not be treated as native 4K generation: BFL says resolutions above 720p are upscaled from 720p generation. Teams can therefore design an evaluation around actual use cases rather than assuming that a higher output label guarantees finer source detail. They can also decide whether a 5-second default is appropriate for their product before exposing longer clips as a routine option.
Limits and uncertainty
The documentation specifies request shapes and parameters, but it does not establish generation quality, completion times, queue performance, or reliability under production load. It gives no pricing figures on this page, so teams should check fal's current billing terms before estimating unit economics. The stated upscaling path also leaves open how much detail is preserved at higher resolutions. These are operational questions to test with representative prompts and assets before committing to a user-facing feature.
The API examples demonstrate accepted request formats, not comparative evidence that one input mode produces better clips than another. A team's own assets, aspect ratios, and tolerance for asynchronous work will determine whether image or keyframe conditioning delivers enough additional control to justify the implementation complexity. The response schema also does not by itself show how a production integration should handle failures or retries.
Skill to build now
Build a small evaluation harness that submits the same prompt as text, with a starting image, and with keyframes. Record completion time, output dimensions, whether generated audio is useful, and how closely motion follows the intended sequence. Keep the clips and request settings together so reviewers can compare controllability, not just visual polish. Include a case at 4K to assess the practical effect of upscaling.
Use the queue URLs as part of the harness rather than treating the call as a blocking request. Store the request ID, poll until completion, and surface the final video URL alongside the prompt and input images. This gives the team a reusable baseline for testing the API before connecting it to customer-facing workflows.
Reader takeaway
FLUX 3 Max is documented as a queued fal API with text, image, and keyframe video inputs, plus controls for duration and output format. The useful builder takeaway is to evaluate those input modes against a concrete product task—and to account for asynchronous jobs and the documented 720p-to-higher-resolution upscaling path.