OpenAI programa para el 24 de septiembre de 2026 la retirada de la API de Sora: qué deben revisar los equipos

La fecha anunciada y los componentes afectados

La documentación de discontinuaciones de OpenAI fija el 24 de septiembre de 2026 como fecha de retirada de Videos API y de los modelos sora-2 y sora-2-pro, además de los snapshots enumerados en esa página. En su columna de sustituto no aparece una alternativa. Por tanto, con la información oficial aportada, los equipos no deberían planificar suponiendo que habrá una migración automática, una extensión del plazo o un modelo de reemplazo compatible.

La fecha indicada es un calendario publicado, no una confirmación de que el servicio ya se haya apagado ni de cómo se comportará exactamente en ese momento. La guía de generación de vídeo documenta actualmente un flujo en el que se crean trabajos de forma asíncrona, se consulta su estado y se descarga el archivo resultante. La referencia de consulta también describe metadatos del trabajo, incluido el campo expires_at para activos descargables. Ninguna de esas descripciones explica qué ocurrirá con solicitudes, trabajos en curso o metadatos una vez alcanzada la fecha de retirada.

La implicación práctica es distinguir dos tareas: preparar la continuidad del producto y preservar los activos propios que ya estén disponibles. Guardar un vídeo descargado puede conservar ese archivo, pero no mantiene por sí mismo la capacidad de generar otros vídeos mediante la integración. A la inversa, que una aplicación conserve una referencia o un identificador de trabajo no demuestra que el activo vaya a seguir siendo recuperable.

No confundir API con aplicación o web

Videos API es una interfaz para que aplicaciones y flujos de trabajo realicen operaciones de generación y recuperación de vídeos mediante solicitudes programáticas. La guía técnica describe la creación de un trabajo, la consulta de su estado y la descarga de su contenido. Eso permite identificar dependencias de software concretas: llamadas a la API, procesamiento de respuestas y componentes que esperan recibir un vídeo o consultar sus metadatos.

La retirada de una API no debe describirse automáticamente como el cierre de una aplicación o de un sitio web para usuarios. Son canales diferentes y pueden tener calendarios, condiciones y herramientas de exportación distintos. Sin embargo, las fuentes verificadas para esta nota documentan la API y no establecen cuándo cerraron —o si cerraron— la aplicación y la web de Sora. Tampoco proporcionan instrucciones de exportación o borrado para esos productos. Por ese motivo, no se puede usar aquí información de exportación de la aplicación para concluir qué ocurrirá con los datos o los activos creados a través de la API.

Esta distinción es relevante para equipos que usan más de un canal. Una biblioteca de vídeos descargados desde la API, una cuenta de usuario en una aplicación y un sistema de producción conectado por API pueden involucrar activos y dependencias distintos. Cada canal requiere verificar sus propias instrucciones oficiales; las fuentes disponibles no permiten unificar esos casos bajo una única política de conservación.

Qué revisar en una integración antes de la fecha

El primer paso es encontrar todas las dependencias, no solo el punto donde se solicita una generación. En la guía técnica, la operación de creación utiliza POST /videos; la consulta de estado emplea GET /videos/{video_id}, y la recuperación del archivo se realiza con GET /videos/{video_id}/content. Esos nombres sirven como pistas para buscar en código, configuración, registros, trabajos programados y servicios de terceros que puedan ocultar la llamada directa.

Después, conviene documentar qué parte del producto depende de cada operación. Por ejemplo, una solicitud puede activar un proceso de edición, esperar a que termine un trabajo y enviar el archivo a almacenamiento o revisión. Si una llamada deja de estar disponible, el fallo podría propagarse a componentes posteriores, aunque la documentación aportada no especifica el código de respuesta ni el comportamiento del servicio tras el apagado. La respuesta adecuada es probar el manejo de errores y diseñar una degradación controlada, no afirmar de antemano cómo responderá el proveedor.

Los equipos también deberían distinguir los activos que ya están en su propio almacenamiento de los que solo se pueden recuperar mediante la API. Para cada vídeo descargado, pueden conservar el archivo y los metadatos que necesiten para identificar su uso, sujeto a sus requisitos internos y derechos aplicables. Para activos que todavía dependan de una operación de recuperación, la documentación revisada no garantiza que continúe disponible después de la fecha indicada.

Ejemplo de inventario y respuesta operativa

Supongamos que un servicio interno recibe solicitudes de vídeo, registra el identificador del trabajo, consulta su estado periódicamente y, cuando está listo, descarga el contenido para enviarlo a un sistema de revisión. El inventario debería registrar por separado cada operación y cada destino posterior. Así se sabrá si el equipo depende de la creación de nuevos vídeos, de la consulta de trabajos ya iniciados, de la descarga de archivos o de las tres cosas.

Si el equipo conserva únicamente el identificador del trabajo, todavía no tiene necesariamente una copia local del vídeo. Si conserva el archivo descargado, puede preservar ese activo en su almacenamiento, pero eso no equivale a mantener la generación habilitada ni demuestra cuánto tiempo seguirán disponibles los metadatos en el servicio. La referencia incluye expires_at como dato asociado a activos descargables; la fuente no explica cómo se aplicaría ese campo después de la retirada.

Una prueba de apagado controlado podría simular respuestas fallidas o indisponibilidad en un entorno de pruebas, y verificar que la cola no repita solicitudes indefinidamente, que los usuarios reciban un estado comprensible y que los procesos aguas abajo no marquen como completado un trabajo sin archivo. Es una recomendación de ingeniería, no una predicción sobre la respuesta concreta de la API. La documentación proporcionada no especifica esa respuesta.

La migración sigue sin estar especificada

La tabla de discontinuaciones no indica un sustituto para los componentes señalados. Eso no prueba que no existan otras herramientas de generación de vídeo, pero sí significa que, con las fuentes revisadas, no hay base para recomendar un reemplazo como migración oficial o compatible. Antes de elegir otra solución, los responsables deberían comprobar qué operaciones ofrece, cómo gestiona los trabajos, qué formatos produce, cuáles son sus condiciones y si satisface los requisitos de seguridad, coste, calidad e integración.

Tampoco se puede afirmar, a partir de estas fuentes, qué ocurrirá con los trabajos que estén pendientes cuando llegue el 24 de septiembre de 2026, si los metadatos seguirán visibles o durante cuánto tiempo, ni si habrá excepciones o cambios posteriores en el calendario. La referencia técnica señala la fecha programada, pero no detalla las consecuencias operativas de ese día. Si OpenAI publica actualizaciones, esas instrucciones deben revisarse antes de tomar decisiones irreversibles.

Para una decisión de servicio, el criterio prudente es separar lo que el equipo puede controlar de lo que depende del proveedor. El equipo puede localizar llamadas, reducir nuevas dependencias, respaldar activos que ya tenga disponibles, registrar metadatos propios y probar el comportamiento de sus sistemas ante errores. No puede deducir de esas acciones la continuidad del endpoint, la conservación de activos remotos o la existencia de una extensión. Conviene asignar responsables y fechas internas para cada tarea y revisar la documentación oficial más cercana al cambio.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.