Animate a sprite through up to three fixed keyframes - initial_image, middle_image and final_image (each a URL or base64) - producing a spritesheet that interpolates through the provided frames in order. initial_image is required: the animation starts from it, and middle_image and final_image add keyframes after it (either may be omitted). The motion_prompt is optional here - when omitted, the motion is derived purely from the keyframes. Runs on hydra (default; also returns `audio_url`), hydra-plus (hydra with finer detail, also returns `audio_url`), forge, or forge-pixel for pixel-art sprites - the models that support a middle keyframe; any other model returns HTTP 400. For just a start and end frame, animateSprite with `final_image` does the same job. The job result is the same sprite result as animateSprite (`spritesheet_url`, `video_url`, grid fields, optional GIF and frame URLs, `audio_url` on hydra and hydra-plus). Credits are held for the duration you requested when the job is accepted; the final charge is rate × seconds of video generated, never more than for the duration you requested, and the difference (or everything, if the job fails or is cancelled) is refunded. The returned sheet is then trimmed to its best loop and can run slightly shorter than the video; that trim is not deducted. Use animateSprite instead for the classic single-image + text-prompt animation. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type spritesheet). Requires an API key (user scope). The call returns 202 with a job id - poll getApiJob (pass wait 30 to long-poll) honouring poll_after_ms, until status is succeeded; its result field is exactly the response documented for this operation. Synchronous responses are deprecated but still supported: pass `async: false` to block until the result is ready and receive it as the response body. Synchronous calls run on the same queue: the response carries an X-Ludo-Job-Id header, and a job still running after 15 minutes comes back as 202 with the job instead of an error. Each account may have up to 50 generations queued or running at once via the API; a request beyond that returns 429 (code PENDING_JOBS_LIMIT).

Optional text description of the desired animation, e.g. "walking", "attack slash". When omitted, the motion is derived purely from the keyframes. When provided, describe exactly and unambiguously what the character should do. Specific or complex actions are fine; there is no need to simplify them. Do not over-describe, though: too much detail can harm the animation, and an action the model already knows should be named, not decomposed into its steps ("walking", never "move the left foot forward, then the right foot"). Do not restate what the keyframes already show (the character, its appearance and equipment, the art style, the background, the lighting, the camera), and leave frame count and timing to the frames and duration fields. Negative phrasing ("no background", "do not move the camera", "without a weapon") works only on hydra and hydra-plus. On forge and forge-pixel it backfires: naming something you do not want makes it more likely to appear, so "without a weapon" tends to produce a weapon. On those models never phrase anything negatively; state only what should happen, and control everything else through the keyframes and the other fields. Keep it well under 100 words: in longer prompts details start competing and some get dropped.

The url OR base64 of the first keyframe. Required - the animation starts from it.

The url OR base64 of the middle keyframe the animation passes through between the initial and final frames. Consecutive keyframes must differ - two identical keyframes in a row produce no motion across that span.

The url OR base64 of the final keyframe. Optional.

Backing model. Hydra (most capable, generates audio) and the Forge family support a middle keyframe; forge-pixel is the pixel-art variant, for sprites whose frames are pixel art.

Trim the animation at the beginning or end to create a seamless loop. Not guaranteed to produce a perfect loop.

Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations.

Maximum number of frames in the output spritesheet. Allow about one second of duration per 16 frames - above that the model may not be able to produce them all (64 frames needs a duration of at least 4). The result can have fewer frames when the duration is short or bad frames were removed.

Size of the sprite in pixels, not of the frame: it sets how big the character is drawn in the exported sheet, and each frame also holds the space around the sprite, so frames come out larger than this value. It changes the export only, not how the sprite is generated. 0 is maximum resolution. -1 is AI 1.5x upscaling. -9 is True Size: frames keep the size and position of the input frame, untrimmed, so the spritesheet lines up exactly with the input image - use it (not margin_ratio_mode "none") whenever the output must align with your input; it works with any margin mode. Exporting larger than the input image adds no detail: do not pick a size above the input's own resolution, and 0 or -1 gain nothing on inputs under 512 px. True Size crops at the input image's edges, so anything the animation adds beyond them (an aura, a spell effect, a swung weapon) is cut off: use a fixed size or 0 for those. adjustSpritesheet re-exports a finished animation at another size for free.

Deprecated: prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0). Sets both axes to this value. A per-axis value, when also given, overrides this for that axis. Supplying any margin value selects margin_ratio_mode "manual" unless margin_ratio_mode is set explicitly.

Horizontal padding around the sprite as a ratio (0.0 to 1.0). Every bit of margin is resolution taken from the sprite, so keep it as tight as the motion allows - about 0.15 - and go higher only for motion that extends sideways (sword slashes, punches) or if the sprite gets cut off. Supplying a value selects margin_ratio_mode "manual" unless margin_ratio_mode is set explicitly; overrides the legacy margin_ratio on this axis.

Vertical padding around the sprite as a ratio (0.0 to 1.0). Every bit of margin is resolution taken from the sprite, so keep it as tight as the motion allows - about 0.15 - and go higher only for motion that extends up or down (jumps) or if the sprite gets cut off. Supplying a value selects margin_ratio_mode "manual" unless margin_ratio_mode is set explicitly; overrides the legacy margin_ratio on this axis.

How the sprite is framed for generation. The model always generates on a canvas of the same size, so any margin is canvas the sprite does not fill: the more margin, the lower the resolution and detail of the sprite. "auto" (default, recommended) trims and centers the sprite and picks a margin suited to the motion. "manual" uses margin_ratio_horizontal / margin_ratio_vertical; keep them as tight as the motion allows (about 0.15) and raise only the axis the motion needs. "none" animates the input exactly as framed, with no trimming and no margin added, so the input must already have suitable margins: a sprite touching the edges gets its limbs, weapons and effects cut off as soon as it moves, and an image that is mostly empty space yields a small, low-detail sprite. "none" is the way to keep a deliberately off-center sprite (e.g. a character at the left edge firing a beam to the right), but results can be unpredictable. Do not use "none" to make the spritesheet line up with the input image - use frame_size -9 (True Size) for that; it works with any margin mode. Rules: omit margin_ratio_mode and send margin_ratio_horizontal / margin_ratio_vertical to get "manual" automatically; "manual" with no margin value fails with HTTP 400; "auto" or "none" sent together with a margin value fails with HTTP 400 (the value would be ignored).

Type of sprite being animated. Affects generation parameters and styling. Tiling types (horizontal / vertical tiles, scrolling backgrounds, parallax layers, textures) stay seamless only on forge and forge-pixel, and only if the input image itself already wraps seamlessly on that axis; otherwise the animation shows a visible seam when tiled.

Animation length in seconds. This endpoint always runs on the Forge model, so only Forge's durations apply - the source of truth is MODEL_PRICING (credits.js), surfaced via /credits/costs.

Rewrites your prompt behind the scenes into the form the model works best with. Leave it on (the default). Turning it off does not give you more control - it usually gives worse results. Do not disable it unless you really know what you are doing and have tested your prompts extensively.

When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time.

When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls.

When true, also returns the spritesheet with background intact (before background removal). Useful for manually fixing background removal issues. The with-background spritesheet URL will be in spritesheet_with_background_url.

Use the animation's pixel grid if one is detected. Defaults to true. true: when Ludo detects a pixel grid with confidence, the sheet is packed on it (logical pixels, scaled up by whole blocks); when none is detected, this has no effect. false: always pack as ordinary art, for when the detected grid is wrong for your asset (for example a smooth sprite coming back as coarse blocks). Ignored for forge-pixel animations, which are always packed on their grid.

Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations.

Defaults to true: the call returns 202 immediately with a job id to poll with getApiJob. Set false for a synchronous response (deprecated but supported): the call then blocks until the result is ready.

URL of the sound effect generated for the animation (MP3 or WAV; the extension says which). hydra and hydra-plus only; absent for forge and forge-pixel.

Number of frames in the spritesheet.

Columns in the frame grid. Frames run left-to-right, top-to-bottom.

Rows in the frame grid. The last row may be only partly filled.

The loop setting the sheet was made with. false is a one-shot animation (an attack, a death) that should play once in an engine.

true when Ludo detected the sprite running past the edges of the frame during the animation, so parts of it are cut off. It is a hint, not a guarantee: look at the frames. The cut is in the generated video, so adjustSpritesheet can't recover it. Call editSpritesheet with edit_mode "outpaint" to extend the frame beyond its borders, or generate again with a larger margin on the axis that was cut (margin_ratio_horizontal / margin_ratio_vertical).

true when Ludo detected that the animation doesn't loop cleanly. It is a hint, not a guarantee. Call editSpritesheet with edit_mode "fix_loop" to repair the loop.