# ¿Qué ocurre con los archivos de entrada y las URL de salida al migrar una aplicación de Sora? > Las referencias de archivo y los enlaces de vídeo del proveedor no son activos portátiles. Conserva los bytes originales bajo ID de activos propios, vuelve a subirlos en el formato de destino, asigna ambos trabajos y copia cada vídeo terminado antes de que caduque. Al migrar una aplicación de Sora, normalmente tendrás que volver a subir o reformatear las referencias de entrada para el proveedor de destino, mientras que las URL de vídeo deben tratarse como ubicaciones temporales de descarga. Coloca ambos lados detrás de una capa de activos que controle archivos duraderos, sumas de comprobación, acceso y asignaciones. Una forma de solicitud compatible no hace portátiles los ID de archivo ni los enlaces de salida. Esos recursos pertenecen al proveedor que los emitió. ## Separa los activos de las referencias del proveedor Usa un ID de activo de la aplicación como clave estable: ```json { "asset_id": "asset_01J...", "kind": "input_image", "sha256": "...", "storage_key": "inputs/asset_01J...png", "provider_refs": { "openai": "provider-specific-reference" } } ``` El ID del archivo de origen, el ID del trabajo de vídeo y la URL firmada son atributos de ese registro, no identificadores permanentes del producto. ## Vuelve a materializar las referencias de entrada El endpoint de vídeo de OpenAI recibe un prompt y puede aceptar una imagen `input_reference` opcional. El destino puede exigir una carga multipart, un ID preexistente, una URL pública o datos base64. Lee cada original desde tu almacenamiento, valida el tipo y las dimensiones y crea la referencia específica del destino. No supongas que un identificador de OpenAI funcionará con otro proveedor. Si solo guardaste una referencia externa, comprueba si todavía puedes descargarla. Si caducó o fue eliminada, será necesaria una nueva carga del usuario; convertir el identificador no recupera los bytes. ## Asigna explícitamente los objetos de trabajo La generación de vídeo de Sora es asíncrona. El trabajo incluye ID, estado, progreso, modelo, duración, tamaño, fechas y posiblemente la caducidad de los activos. Guarda el trabajo de destino junto al de origen: | Campo de la aplicación | Asignación de origen | Asignación de destino | |---|---|---| | ID interno de trabajo | Tu base de datos | Mismo valor | | ID de trabajo del proveedor | ID de vídeo de OpenAI | ID del destino | | Estado | Estado de origen | Estado normalizado | | Activo de entrada | Referencia de origen | Nueva referencia de destino | | Activo de salida | Bytes descargados | Bytes descargados del destino | No sobrescribas la asignación de origen durante una migración gradual. Mantener ambas facilita la reversión y el soporte. ## Descarga el contenido, no solo la URL La API de OpenAI expone un endpoint de contenido para un vídeo completado e informa `expires_at` cuando los activos caducan. Una URL copiada puede dejar de funcionar, exigir autenticación o no ser adecuada para clientes. Al finalizar, el trabajador debe: 1. recuperar el contenido desde el endpoint autenticado; 2. transmitirlo a almacenamiento de objetos propio; 3. verificar tipo, tamaño y suma de comprobación; 4. registrar procedencia, modelo, política del prompt y parámetros; 5. servirlo mediante una URL autorizada de la aplicación. Aplica lo mismo a miniaturas, vistas previas y otras variantes necesarias. ## Planifica la retención y la privacidad Copiar archivos cambia el ámbito de gobierno. Define retención por separado para cargas, elementos intermedios, vídeos finales, miniaturas y trabajos fallidos. Cifra los activos, limita los roles y evita registrar URL firmadas o prompts brutos. Ante una solicitud de eliminación, borra la copia propia y llama al proveedor cuando exista un endpoint apropiado. Conserva un marcador no sensible para que los reintentos sean idempotentes. ## Prueba el comportamiento de los medios Crea casos para cada formato, orientación, resolución, duración y tamaño máximo. Comprueba canales alfa y perfiles de color cuando importen. En las salidas, prueba enlaces caducados, descargas parciales, tipo incorrecto, solicitudes de rango, cancelación y recuperación tras un fallo del trabajador. Compara también las políticas de contenido y moderación. Que ambos proveedores acepten la forma de una solicitud no garantiza el mismo resultado. ## En resumen Las referencias de Sora y sus URL son recursos del proveedor, no activos portátiles. Conserva los originales, crea referencias nuevas, descarga pronto los vídeos y expón ID de activo propios. Así la migración puede revertirse y un enlace caducado no se convierte en pérdida de datos. ## FAQ ### ¿Se puede enviar un input_reference de OpenAI a otro proveedor de vídeo? Por lo general no. Lee el original desde tu almacenamiento y crea la carga multipart, el ID de archivo, la URL o la referencia base64 que exija el destino. ### ¿Las URL de salida de Sora son permanentes? Trátalas como ubicaciones temporales o autenticadas. El trabajo puede incluir una fecha de caducidad, así que descarga pronto el contenido a almacenamiento propio. ### ¿Qué hago si solo guardé un ID de archivo del proveedor? Intenta recuperar los bytes mientras el recurso siga disponible. Si caducó o fue eliminado, puede ser necesario que el usuario vuelva a subir el original. ### ¿Qué ID debe exponer la aplicación? Expón tus ID estables de activo y trabajo. Conserva los ID de origen y destino como asignaciones para recuperación, soporte y reversión. ### ¿Debo sobrescribir la asignación de origen después del cambio? No. Conserva ambas asignaciones durante la migración gradual para comparar el comportamiento y poder revertir. ### ¿Qué debe probarse en los activos de vídeo? Prueba cada formato, tamaño, duración, orientación y variante admitidos, además de caducidad, descargas parciales, cancelación y reintentos de almacenamiento.