# O que acontece com arquivos de entrada e URLs de saída ao migrar um aplicativo Sora? > Referências de arquivo e links de vídeo do provedor não são ativos portáteis. Guarde os bytes originais sob IDs próprios, reenvie no formato do destino, mapeie os dois trabalhos e copie cada vídeo concluído antes que os recursos expirem. Ao migrar um aplicativo Sora, as referências de entrada normalmente precisam ser reenviadas ou reformatadas para o provedor de destino, enquanto as URLs de vídeo devem ser tratadas como locais temporários de download. Coloque os dois lados atrás de uma camada de ativos que controle arquivos duráveis, checksums, acesso e mapeamentos. Um formato de solicitação compatível não torna IDs de arquivo nem links de saída portáteis. Esses recursos pertencem ao provedor que os emitiu. ## Separe ativos de referências do provedor Use um ID de ativo da aplicação como chave estável: ```json { "asset_id": "asset_01J...", "kind": "input_image", "sha256": "...", "storage_key": "inputs/asset_01J...png", "provider_refs": { "openai": "provider-specific-reference" } } ``` O ID do arquivo de origem, o ID do trabalho de vídeo e a URL assinada são atributos desse registro, não identificadores permanentes do produto. ## Recrie as referências de entrada O endpoint de vídeo da OpenAI recebe um prompt e pode aceitar uma imagem `input_reference` opcional. O destino pode exigir upload multipart, ID de arquivo previamente enviado, URL pública ou dados base64. Leia cada original do seu armazenamento, valide tipo e dimensões e crie a referência específica do destino. Não presuma que um identificador da OpenAI funcione em outro provedor. Se você guardou apenas uma referência externa, confirme se ainda é possível baixá-la. Quando ela tiver expirado ou sido removida, o usuário precisará reenviar o arquivo; converter o identificador não recupera bytes ausentes. ## Mapeie explicitamente os objetos de trabalho A geração de vídeo do Sora é assíncrona. O trabalho possui ID, estado, progresso, modelo, duração, tamanho, datas e, possivelmente, expiração dos ativos. Guarde o trabalho de destino ao lado do trabalho de origem: | Campo da aplicação | Mapeamento de origem | Mapeamento de destino | |---|---|---| | ID interno do trabalho | Seu banco de dados | Mesmo valor | | ID do trabalho no provedor | ID de vídeo da OpenAI | ID do destino | | Estado | Estado de origem | Estado normalizado | | Ativo de entrada | Referência de origem | Nova referência de destino | | Ativo de saída | Bytes baixados | Bytes baixados do destino | Não sobrescreva o mapeamento de origem durante uma migração gradual. Manter os dois permite reversão e investigações de suporte. ## Baixe o conteúdo, não apenas a URL A API da OpenAI expõe um endpoint de conteúdo para vídeos concluídos e informa `expires_at` quando os ativos expiram. Uma URL copiada pode parar de funcionar, exigir autenticação ou não ser adequada para clientes. Na conclusão, o worker deve: 1. obter o conteúdo pelo endpoint autenticado; 2. transmiti-lo para armazenamento de objetos próprio; 3. verificar tipo, tamanho e checksum; 4. registrar origem, modelo, política de prompt e parâmetros; 5. servi-lo por uma URL autorizada da aplicação. Faça o mesmo para miniaturas, prévias e outras variantes necessárias ao produto. ## Planeje retenção e privacidade Copiar arquivos muda o escopo de governança. Defina retenção separada para uploads, intermediários, vídeos finais, miniaturas e trabalhos com falha. Criptografe ativos, restrinja funções de serviço e não registre URLs assinadas nem prompts brutos. Ao receber uma solicitação de exclusão, remova a cópia da aplicação e chame o provedor quando houver endpoint apropriado. Preserve um marcador não sensível para que novas tentativas sejam idempotentes. ## Teste o comportamento da mídia Crie casos para cada formato, orientação, resolução, duração e tamanho máximo. Verifique canais alfa e perfis de cor quando forem relevantes. Para saídas, teste links expirados, downloads parciais, tipo incorreto, solicitações de intervalo, cancelamento e retomada após falha do worker. Compare também políticas de conteúdo e moderação. Dois provedores aceitarem o formato não garante o mesmo resultado. ## Em resumo Referências do Sora e URLs de saída são recursos do provedor, não ativos portáteis. Guarde os originais, crie referências novas, baixe vídeos prontamente e exponha IDs de ativo próprios. Assim, a migração pode ser revertida e um link expirado não se torna perda de dados. ## FAQ ### Um input_reference da OpenAI pode ser enviado a outro provedor de vídeo? Geralmente não. Leia o original do seu armazenamento e crie o upload multipart, ID de arquivo, URL ou referência base64 exigida pelo destino. ### As URLs de saída do Sora são permanentes? Trate-as como locais temporários ou autenticados. O trabalho pode informar expiração, então baixe o conteúdo rapidamente para seu armazenamento. ### E se eu tiver guardado apenas um ID de arquivo do provedor? Tente recuperar os bytes enquanto o recurso existir. Se tiver expirado ou sido excluído, o usuário talvez precise reenviar o original. ### Qual ID o aplicativo deve expor? Exponha seus IDs estáveis de ativo e trabalho. Preserve IDs de origem e destino como mapeamentos para recuperação, suporte e reversão. ### Devo sobrescrever o mapeamento de origem após a mudança? Não. Mantenha os dois mapeamentos durante a migração gradual para comparar o comportamento e permitir reversão. ### O que deve ser testado nos ativos de vídeo? Teste formatos, tamanhos, durações, orientações, variantes, expiração, downloads parciais, cancelamento e novas tentativas de armazenamento.