Flujo de trabajo de la API de imagen a vídeo: Runway, Wan 2.7, Vidu y patrones de API en producción

Tienes una imagen estática —un render de producto, un key visual ya aprobado, una hoja de diseño de personaje— y necesitas ponerla en movimiento. No generar una escena nueva más o menos parecida, sino animar ese fotograma mismo. Eso es exactamente lo que hace la imagen a vídeo (i2v), y es una forma de integración completamente distinta a «introducir un prompt y esperar que el modelo dibuje lo que tienes en la cabeza». Este artículo es la versión práctica: preparar la imagen de origen, controlar dónde empieza y dónde termina el movimiento, escribir prompts que dirijan la animación en lugar de redescribir la escena, y gestionar el sondeo y los callbacks para que un render de varios minutos no tumben tu backend.

¿Aún dudas sobre si usar i2v en lugar de texto a vídeo? Este artículo da por hecho que ya lo has decidido y quieres sacarle partido a i2v.

Cuándo conviene usar imagen a vídeo

Cuando el fotograma inicial no es negociable, toca usar i2v. El modelo no crea el sujeto de la nada: recibe tu imagen y le añade movimiento, así que todo lo que deba mantener la coherencia de marca o de diseño obtiene una garantía que el texto a vídeo no puede ofrecer: renders de producto de un SKU real, convertir un key visual aprobado en un bucle de cabecera, hojas de diseño de personaje con rostro consistente, o efectos antes→después con fotograma inicial y final fijos y el modelo rellenando la transición. Si el sujeto es flexible, texto a vídeo suele dar menos trabajo. El valor central de i2v es precisamente que la imagen estática es fija.

El panorama de imagen a vídeo en 2026

El terreno de i2v está muy disputado y es exigente. Merece la pena conocerlo como contexto, aunque el flujo de trabajo invocable que sigue se ejecuta sobre un conjunto seleccionado de modelos:

• Runway Gen-4 / Gen-4.5. El sucesor de Gen-3 Alpha; impulsó la «consistencia de mundo» entre planos, el movimiento basado en física y los movimientos de cámara deliberados. El i2v de Gen-4.5 se considera ampliamente la mejor opción para un control creativo ajustado en publicidad o entregables a cliente (Runway Research, «Introducing Runway Gen-4», 2026; resumen de modelos de ZNIX, 2026). Runway Gen-4.5 imagen a vídeo también está disponible en HiAPI con el ID de modelo runway-gen-4.5/image-to-video; consulta la guía de la API de Runway Gen-4.5.
• Vidu Q3. Construido en torno al condicionamiento de primer y último fotograma —fotograma inicial, fotograma final objetivo, prompt de cambio, y él rellena el tramo intermedio—, con soporte de hasta 16 segundos en 1080p con audio (Vidu, «AI Image to Video», 2026).
• Kling 3.0. Destaca en generar movimiento humano complejo a partir de una imagen estática de referencia, con soporte nativo de 4K y sincronización labial (TeamDay.ai, «Best AI Video Models 2026», 2026).
• Seedance 2.0. El modelo de ByteDance (12 de febrero de 2026) mantiene estables los detalles de producto, logotipos y texto entre fotogramas, justo lo que necesita el i2v de comercio electrónico (opencreator.io, «AI Video Models Comparison 2026», 2026).

El patrón es consistente entre los modelos fuertes: el control del primer fotograma es un requisito básico, el control del último fotograma ya no es raro, y anclar ambos extremos es el método más fiable para evitar que el clip derive en el último segundo. El flujo de trabajo que sigue está construido precisamente en torno a ese principio. En HiAPI, los dos modelos i2v que puedes invocar son Seedance 2.0 (ByteDance) y Wan 2.7 imagen a vídeo (Alibaba).

Paso 1 — Preparar la imagen de origen

Este es el paso que la gente suele saltarse y luego culpa al modelo. Con i2v, tu primer fotograma es el techo de calidad. Antes de enviar nada, hay que hacer tres cosas:

• Coincidir la relación de aspecto con la salida. Renderizar la fuente en 4:3 y pedir un clip en 16:9 obliga al modelo a recortar o rellenar, y pierdes el control sobre lo que se conserva al final. Decide primero la proporción de salida y produce la imagen estática en esa proporción. Seedance además acepta la proporción adaptive, que se ajusta automáticamente al tamaño de la imagen de origen.
• Renderizar a la resolución de salida deseada. Una fuente en 480p no se convertirá en un clip nítido en 1080p; ampliar una entrada borrosa solo hace que el desenfoque se mueva.
• Componer el sujeto con limpieza. Un sujeto claro y sin desorden hace que el modelo se equivoque menos. Los fondos recargados y los bordes borrosos son justo el origen de movimientos extraños.

Después, alójala. La API recibe la imagen de origen como URL (first_frame_url), no como subida de archivo, así que debe ser accesible por HTTPS: tu bucket, CDN o almacenamiento de objetos firmado. Una ruta localhost o un enlace que la API no pueda recuperar hará fallar la tarea.

Paso 2 — Enviar la tarea con el primer fotograma

En HiAPI, cada modelo (también los de vídeo) se ejecuta mediante una API de tareas asíncrona. Creas una tarea, recibes al instante un taskId y el render ocurre en el servidor. Convertir texto a vídeo en imagen a vídeo requiere un solo campo: añadir first_frame_url. Esta es la llamada mínima, con Seedance 2.0:

curl -X POST https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer sk-<your-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedance-2-0",
    "input": {
      "prompt": "Slow cinematic push-in, a soft light sweep travels across the surface, the subject holds steady and in focus",
      "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg",
      "aspect_ratio": "16:9",
      "duration": 5,
      "resolution": "720p",
      "generate_audio": false
    }
  }'

Esa es la solicitud completa de imagen a vídeo. Los campos de entrada importantes:

• first_frame_url — la imagen estática que se va a animar; su presencia es precisamente la clave de i2v.
• aspect_ratio — coincide con la imagen de origen (o usa adaptive).
• duration — segundos de salida; cuanto más largo, más cuesta y más margen tiene el movimiento para derivar.
• resolution — 480p / 720p / 1080p; el principal ajuste de coste.
• generate_audio — déjalo desactivado para bucles silenciosos y renders de producto.

La estructura completa de solicitud y respuesta está en la documentación. Wan 2.7 imagen a vídeo sigue el mismo flujo de crear-sondear-descargar, pero sus entradas son distintas: lleva los fotogramas de origen en el array media y produce 720p o 1080p, así que consulta la documentación para conocer su estructura exacta en lugar de reutilizar directamente el cuerpo de solicitud de Seedance.

Paso 3 — Añadir el último fotograma cuando importa el desenlace

El primer fotograma controla dónde empieza el clip y deja que el modelo decida cómo termina; ahí es donde aparece la deriva sin avisar, porque el modelo improvisa la segunda mitad. Si la continuidad con el último fotograma importa, fíjalo también:

{
  "model": "seedance-2-0",
  "input": {
    "prompt": "The product rotates a quarter turn and settles, light resolving to a clean studio key",
    "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg",
    "last_frame_url": "https://cdn.your-domain.com/assets/product-three-quarter.jpg",
    "aspect_ratio": "16:9",
    "duration": 5,
    "resolution": "720p"
  }
}

Ahora ambos extremos están fijos y el modelo solo rellena el movimiento entre ellos. Este es el patrón principal para revelaciones de producto y transiciones antes→después, y también la corrección única más eficaz para el problema de «el clip está bien hasta el último segundo». Mantén ambos fotogramas con el mismo sujeto y composición: si las imágenes de inicio y fin difieren demasiado, el modelo tendrá que inventar un camino entre ambas y volverás al terreno de las conjeturas.

Paso 4 — Escribir prompts de movimiento para una imagen estática

Los prompts cumplen una función distinta en i2v, y equivocarse desperdicia renders. En texto a vídeo, el prompt construye la escena entera. En imagen a vídeo, el modelo ya ve la escena —está en el fotograma que le das—, así que la función del prompt es el cambio a lo largo del tiempo, no el contenido:

• Empieza por el movimiento de cámara. «Slow dolly-in», «gentle pan left», «push-in then hold». Los modelos de movimiento siguen los verbos de cámara de forma fiable; dales uno explícito.
• Describe cómo se mueve el sujeto, no qué es. «Steam begins to rise», «the fabric sways», «the screen wakes and glows». Estás coreografiando la animación, no reenumerando objetos.
• No redescribas la imagen. Repetir lo que ya es evidente en la imagen de origen compite contra el modelo y puede empujarlo a regenerar en lugar de animar.
• Haz que el movimiento encaje en la duración. Un clip de 5 segundos no puede contener una historia de 20 segundos.

Un buen prompt de i2v se lee como una indicación de acción para un cámara, no como una descripción de escena para un pintor.

Paso 5 — Sondear o recibir callbacks

El vídeo consume minutos de GPU, no milisegundos. El render es asíncrono por diseño, así que nunca mantendrá una conexión abierta. Una vez creada la tarea, tienes dos formas de saber que ha terminado.

Sondeo hasta alcanzar un estado terminal; útil para scripts y prototipos:

curl https://api.hiapi.ai/v1/tasks/<taskId> \
  -H "Authorization: Bearer sk-<your-key>"
# data.status: queued -> handling -> archiving -> success (or fail)
# on success, read data.output[0].url and download it promptly — the URL expires

Recibir callbacks es lo adecuado para cualquier cosa que vaya más allá de un prototipo. En lugar de sentarte en un bucle de sondeo, pasa un callback y deja que HiAPI te envíe el estado terminal:

{
  "model": "seedance-2-0",
  "input": { "prompt": "...", "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg", "aspect_ratio": "16:9", "duration": 5, "resolution": "720p" },
  "callback": { "url": "https://your-domain.com/hooks/hiapi", "when": "final" }
}

En ambos casos, la URL de salida tiene caducidad. En cuanto la tarea pase a success, descarga data.output[0].url a tu propio almacenamiento de inmediato; no la enlaces en caliente en una página ni la entregues al cliente, porque expirará.

Patrones de producción que resisten

Unos cuantos hábitos separan un script de demostración de algo que funciona a escala:

• Prefiere callbacks al sondeo cuando escales. Un bucle de sondeo por tarea es un desperdicio de cómputo y una fuente de presión sobre los límites de peticiones. Un único endpoint de callback que descarga resultados y actualiza tus registros escala mucho mejor que cientos de sondeadores.
• Haz idempotente el envío. Los reintentos y los callbacks de al menos una vez ocurren. Da a cada render un ID estable (imagen de origen + prompt + parámetros, con hash) para que un reintento no genere —ni facture— silenciosamente un clip duplicado.
• El coste es resolución × duración. El vídeo se factura por segundo y la tarifa sube con la resolución, así que un clip de 10 segundos en 1080p cuesta mucho más que uno de 5 segundos en 480p. Itera en 480p, fija el prompt y el movimiento de cámara, y vuelve a renderizar solo los clips conservados a la resolución de entrega. Consulta las tarifas en tiempo real en la página de precios; cambian, así que no las codifiques en duro.
• Presupuesta por clips utilizables, no por renders. Si de tres clips conservas uno, tu coste real por activo entregable es el triple del precio de tarifa; esa ratio, y no la tarifa por segundo, es la que determina tu presupuesto, y por eso fijar el prompt en 480p se amortiza.
• Valida la URL de origen pronto. Un primer fotograma que la API no puede recuperar es el fallo evitable más común; comprueba antes de enviar que es accesible por HTTPS.

Preguntas frecuentes

¿En qué se diferencia imagen a vídeo de texto a vídeo en la solicitud? En un campo. La llamada a la tarea es idéntica en todo lo demás; añadir first_frame_url (la imagen de origen) la convierte de texto a vídeo en imagen a vídeo. En HiAPI, ambas se ejecutan por el mismo endpoint POST /v1/tasks.

¿Puedo controlar el primer y el último fotograma a la vez? Sí. first_frame_url fija el fotograma inicial; añadir last_frame_url fija el fotograma final, de modo que el modelo solo rellena el movimiento entre los dos extremos fijos. Fijar ambos extremos es el método más fiable para controlar transiciones y evitar la deriva al final del clip.

¿Las API de Runway Gen-3/Gen-4 admiten imagen a vídeo? Las series Gen-3 y Gen-4 de Runway admiten imagen a vídeo y destacan en control cinematográfico; ese es el panorama general. El flujo de trabajo invocable de esta guía se ejecuta sobre Seedance 2.0 y Wan 2.7 imagen a vídeo, que HiAPI aloja tras una única API de tareas. Runway Gen-4.5 imagen a vídeo funciona sobre la misma API; en la guía de la API de Runway Gen-4.5 hay un ejemplo de solicitud funcional.

¿Cuánto tarda un render de imagen a vídeo? Minutos, no segundos: el vídeo es cómputo real. Por eso la API es asíncrona: creas la tarea y luego sondeas o recibes un callback, de modo que un render largo nunca bloquea tu petición.

Resumen de puntos clave

La imagen a vídeo encaja cuando una imagen estática concreta debe aparecer en pantalla tal cual y luego ponerse en movimiento. El techo de calidad lo decide la resolución, la relación de aspecto y la composición de la imagen de origen antes de que escribas el primer prompt, así que prepárala primero y alójala en una ubicación estable. Fija el primer fotograma para controlar dónde empieza el clip, añade el último cuando el desenlace deba quedar cerrado, y escribe el prompt como dirección de movimiento y cámara en lugar de redescribir lo que el modelo ya puede ver. Después trátalo como la tarea asíncrona que es: sondea o, mejor, recibe callbacks; haz idempotentes los envíos; descarga antes de que caduque la URL; y presupuesta por clips utilizables a la resolución de entrega.

Cuando estés listo, ejecuta tu imagen de origen desde la página del modelo Seedance 2.0 o desde Wan 2.7 imagen a vídeo, conecta después la API de tareas de arriba y, antes de escalar, revisa las tarifas por segundo en tiempo real en la página de precios. (¿Buscas primero opciones sin clave? Consulta las opciones gratuitas de texto a vídeo.)