OpenAI Sora API en 2026: como usar la API oficial de Videos

Si por "OpenAI Sora API" te refieres a la generacion de video programatica oficial en la plataforma de OpenAI, la respuesta es si: la superficie actual para desarrolladores es la Videos API, centrada en POST /v1/videos y en los modelos sora-2 y sora-2-pro. La confusion aparece porque OpenAI tambien tiene una app / editor Sora para consumidores y acceso a Sora dentro de ChatGPT, y esas superficies no usan el mismo lenguaje de "API". Por eso la SERP sigue pareciendo contradictoria incluso en marzo de 2026.

Esta guia responde a la pregunta del desarrollador, no a la del usuario de la app. Se centra en el contrato oficial que existe hoy, en el flujo mas corto de create -> wait -> download, en las restricciones de precio y politica que importan antes de construir, y en los cambios de marzo de 2026 que dejaron incompletos muchos resumenes antiguos sobre Sora API.

Nota de frescura: verificado contra la documentacion actual de OpenAI Developers, pricing, paginas de modelo y materiales del help center el 28 de marzo de 2026.

TL;DR

• Hoy si existe acceso oficial para desarrolladores. La superficie correcta es /v1/videos, no el editor Sora para consumidores.
• Empieza con sora-2 cuando estes iterando prompt, encuadre o movimiento a menor coste.
• Pasa a sora-2-pro cuando necesites una salida mas pulida, especialmente si quieres 1920x1080 o 1080x1920.
• Disena el flujo como asincrono desde el principio. Crea el job, consulta GET /videos/{video_id} o usa webhooks, y luego descarga con GET /videos/{video_id}/content.
• La documentacion de Sora en OpenAI esta parcialmente desincronizada. La guia actual y el changelog de marzo de 2026 ya documentan 16/20 segundos, edits, extensions, reusable characters, Batch y 1080p en sora-2-pro, mientras que algunos fragments de referencia mas viejos siguen mostrando duraciones mas cortas y limites menores.

Que significa realmente "OpenAI Sora API" ahora mismo

El error mas comun en este tema es tratar Sora como si fuera una sola superficie de producto. En la practica, hay al menos tres:

Esa separacion explica por que paginas oficiales de OpenAI pueden sonar inconsistentes. El Help Center sigue teniendo contenido centrado en la app, y ese contenido habla del producto de consumo. La documentacion para desarrolladores, en cambio, ya documenta un stack activo de Video generation with Sora con endpoints, modelos, precios y ejemplos actuales.

Por eso, el modelo mental mas fiable hoy es este:

No integres "la app Sora". Integra la Videos API de OpenAI.

Suena obvio una vez dicho, pero justo esa aclaracion es la que mas falta hace en los resultados de busqueda actuales.

La ruta mas rapida que funciona hoy con OpenAI

Si solo necesitas el camino oficial mas corto desde cero hasta un resultado util, el flujo es directo.

Primero llama a POST /v1/videos con un prompt, un modelo, un size y una duracion. OpenAI trata la generacion de video como un job asincrono, asi que la respuesta inicial solo indica que el job existe y que ha entrado en estados como queued o in_progress. Despues, o bien haces polling a GET /v1/videos/{video_id} hasta que el estado sea completed, o registras un webhook y dejas que OpenAI te avise con video.completed o video.failed. Cuando el job termina, recuperas el binario desde GET /v1/videos/{video_id}/content.

Para prototipos, el polling suele bastar. Para produccion, el webhook es un contrato mas limpio, porque los renders largos pueden tardar minutos y no quieres quemar requests solo para enterarte de que el job sigue en marcha.

Aqui tienes la ruta minima en JavaScript usando el patron actual del SDK de OpenAI:

javascript
import OpenAI from "openai";
import { writeFile } from "node:fs/promises";

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const video = await openai.videos.createAndPoll({
  model: "sora-2",
  prompt:
    "Wide tracking shot of a yellow taxi crossing a rain-soaked city street at blue hour, neon reflections, natural ambient audio.",
  size: "1280x720",
  seconds: "8",
});

if (video.status !== "completed") {
  throw new Error(`Video failed with status ${video.status}`);
}

const content = await openai.videos.downloadContent(video.id);
const buffer = Buffer.from(await content.arrayBuffer());

await writeFile("video.mp4", buffer);
// In production, copy the file into your own object storage immediately.

Y el mismo lifecycle en HTTP puro:

bash
curl -X POST "https://api.openai.com/v1/videos" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -F model="sora-2" \
  -F prompt="Wide tracking shot of a yellow taxi crossing a rain-soaked city street at blue hour, neon reflections, natural ambient audio." \
  -F size="1280x720" \
  -F seconds="8"

curl "https://api.openai.com/v1/videos/$VIDEO_ID" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

curl -L "https://api.openai.com/v1/videos/$VIDEO_ID/content" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  --output video.mp4

Ese es el nucleo de la integracion. Todo lo demas del stack actual de Sora se construye alrededor de ese modelo de job.

Precios, modelos y el desfase de documentacion que los desarrolladores deben vigilar

La pricing page oficial actual deja claro el reparto entre modelos. sora-2 es la opcion mas barata y rapida para iterar. sora-2-pro ofrece una salida mas pulida y es la ruta necesaria si quieres exportar en 1080p.

La documentacion de precios muestra hoy esta estructura por segundo para uso standard:

Y para Batch, la misma escalera aparece a mitad de precio:

Eso ya te da la mayor parte de lo que importa operativamente:

• Si estas explorando prompts, empieza por sora-2.
• Si estas produciendo assets finales y te importa mas el acabado, pasa a sora-2-pro.
• Si vas a renderizar un shot list offline, la economia de Batch ya justifica evaluarlo con seriedad.

El punto mas sutil, pero tambien mas importante, es este: la documentacion de Sora en OpenAI esta parcialmente fuera de sync. Esto no es una suposicion, sino una inferencia basada en fuentes oficiales actuales:

• la guia principal dice que sora-2 y sora-2-pro soportan generaciones de 16 y 20 segundos,
• el changelog de marzo de 2026 dice explicitamente que Sora API se expandio a generaciones mas largas de hasta 20 segundos y 1080p en sora-2-pro,
• pero fragments de referencia mas antiguos siguen mostrando solo 4, 8, 12 segundos y una matriz de tamanos mas reducida.

Si quieres entender el contrato vigente hoy, la lectura mas segura es esta:

cuando la guia actual, la pricing page y el changelog de marzo de 2026 no coincidan con fragments de referencia antiguos, confia primero en los primeros.

Ese aviso merece estar por escrito porque puede afectar directamente a tu selector de resolucion, tu planificacion de capacidad y tu mensaje de producto.

Lo que la API oficial puede hacer ademas de text-to-video simple

La guia actual ya no es solo un punto de entrada de text-to-video. El stack Sora actual cubre un lifecycle mas amplio de generacion e iteracion.

Referencias de imagen

Puedes guiar una generacion con input_reference, ya sea como asset subido en multipart o como objeto JSON con file_id o image_url. OpenAI describe la imagen de referencia como el equivalente al primer fotograma del clip. La restriccion importante es que la imagen debe coincidir con el size objetivo, y los formatos documentados son image/jpeg, image/png y image/webp.

Esto hace que las referencias de imagen sean utiles para brand assets, direccion visual o casos donde importa mas fijar la composicion inicial que reutilizar un personaje entre muchos jobs.

Personajes reutilizables

OpenAI documenta ahora el characters workflow para crear assets reutilizables no humanos a partir de video subido. En la guia actual, characters se presentan como una herramienta de consistencia para animales, mascotas u objetos, y la API permite hasta dos characters en una sola generacion. La guia tambien dice que las subidas con apariencia humana estan bloqueadas por defecto, algo importante si dabas por hecho que esta superficie servia para "entrenar" un actor real.

La conclusion practica es simple: usa characters para sujetos no humanos reutilizables, no como un atajo para rodear las restricciones sobre personas reales.

Extensions de video

OpenAI ya documenta video extensions para continuar un clip ya completado. Esa es la ruta correcta si quieres preservar movimiento, direccion de camara y continuidad de escena. Si solo necesitas controlar el primer fotograma de una nueva generacion, input_reference sigue siendo mejor. La guia actual dice que cada extension puede anadir hasta 20 segundos, que un solo video puede extenderse hasta 6 veces y que las extensions no soportan characters ni image references.

Ese ultimo detalle importa mucho. Si tu diseno de producto asume que todas las features avanzadas se componen libremente, te vas a salir del contrato real.

Edits de video

El changelog de marzo de 2026 anadio el video edits workflow, que ahora es la ruta preferida para hacer cambios concretos sobre un video generado o subido. La guia dice explicitamente que la ruta remix anterior se esta deprecando y que edits funciona mejor cuando el cambio pedido es pequeno y bien definido.

Eso indica que OpenAI esta tratando Sora menos como un generador de una sola pasada y mas como un workflow iterativo de medios.

Batch

La guia actual ya soporta Batch para POST /v1/videos, con varias restricciones importantes:

• Batch soporta solo POST /v1/videos.
• Las requests de Batch deben ser JSON, no multipart.
• Debes subir los assets antes y referenciarlos desde el body JSON.
• Los videos generados en Batch quedan disponibles para descarga hasta 24 horas despues de que el batch termine.

Si estas construyendo colas de render offline, workflows de estudio o pipelines de shot list, Batch ya no es algo secundario. Forma parte de la ruta oficial.

Guardrails y puntos operativos que importan antes de construir

El stack de Sora ya tiene suficientes restricciones como para tratar politica y retencion como parte del contrato de producto, no como simples notas de compliance.

La guia actual dice que la API aplica todas estas restricciones:

• el contenido debe ser apto para menores de 18 anos,
• los personajes con copyright y la musica con copyright seran rechazados,
• no se pueden generar personas reales ni figuras publicas,
• las subidas de characters con apariencia humana estan bloqueadas por defecto,
• y las imagenes de entrada con rostros humanos se rechazan actualmente.

Si tu workflow planeado depende de cualquiera de esos puntos, no tienes un caso de borde pequeno. Tienes un problema de routing.

El modelo de almacenamiento tambien importa. OpenAI dice que las URLs directas de descarga son validas durante un maximo de 1 hora tras la generacion. Las descargas de Batch duran hasta 24 horas despues de que el batch termina. Eso significa que las URLs alojadas por el proveedor deben tratarse como assets temporales de entrega, no como almacenamiento duradero. En produccion, copiar el output a tu propio object storage deberia formar parte del workflow normal de finalizacion.

La latencia tambien importa. La guia dice que un solo render puede tardar varios minutos segun el modelo, la carga y la resolucion. Eso convierte background jobs, estados de progreso, retries y manejo de completado via webhook en la opcion normal, no en una sofisticacion solo para empresas grandes.

Por ultimo, el acceso y los limites de velocidad dependen del usage tier. La guia de Rate limits dice que las organizaciones suben de tier a medida que aumenta el gasto y recomienda consultar la pagina Limits de tu cuenta para ver el cap efectivo actual. Las paginas de modelo de Sora tambien muestran limites ligados al tier, pero el renderizado actual del indice de busqueda es demasiado resumido, asi que es mas seguro mandar al lector a la vista en vivo de Limits que sobreinterpretar numeros parcialmente etiquetados.

Que superficie de OpenAI deberias usar realmente

Si tu objetivo real es construir un producto, la respuesta es Videos API.

Si tu objetivo real es generar unos pocos videos manualmente, ChatGPT o la app Sora pueden seguir siendo mejor opcion, porque no necesitas gestionar async jobs, storage ni webhooks.

La distincion parece pequena, pero en realidad es lo que resuelve todo el tema. Gran parte de la confusion sobre "OpenAI Sora API" viene de leer ayuda orientada a la app de Sora, despues leer docs orientadas a desarrolladores para Videos API, y asumir que una de las dos superficies debe estar equivocada. En realidad, estan describiendo trabajos distintos.

Para desarrolladores, la respuesta corta y correcta es esta:

Si, OpenAI ya ofrece generacion de video programatica oficial. Integra la Videos API, no la superficie de consumo de Sora.

FAQ

OpenAI soporta oficialmente hoy la generacion de video Sora por API?

Si. La ruta oficial para desarrolladores es la Videos API actual de OpenAI, documentada en la guia de video generation y en la referencia de POST /v1/videos.

Por que algunas paginas de OpenAI siguen haciendo que Sora parezca no tener API?

Porque algunas superficies oficiales siguen hablando de la app / editor Sora para consumidores, no de la Videos API para desarrolladores. Esa diferencia es la raiz de la confusion actual en buscadores.

Con que modelo deberia empezar?

Empieza con sora-2 para iterar prompts y hacer corridas mas baratas. Cambia a sora-2-pro cuando necesites una salida de mas calidad, especialmente 1080p.

1080p esta oficialmente disponible?

Si. La guia actual, la documentacion de precios y el changelog de marzo de 2026 documentan 1080p en sora-2-pro, y el changelog incluso dice explicitamente que las generaciones 1080p en sora-2-pro se cobran a \$0.70/sec.

Puedo fiarme solo del polling?

Para prototipos, si. Para produccion, los webhooks son mas limpios porque los renders pueden tardar minutos y no quieres que un loop de polling sea tu control plane normal.

Puedo construir un flujo con reusable characters y luego extender el mismo clip?

No como un workflow completamente componible hoy. La guia actual dice que extensions no soporta characters ni image references, asi que conviene disenar esa parte con cuidado.