# Vad händer med indatafiler och utdata-URL:er när du migrerar en Sora-app? > Leverantörens filreferenser och videolänkar är inte portabla tillgångar. Bevara originalbytes under egna tillgångs-ID:n, ladda upp dem i målformatet, mappa käll- och måljobb separat och kopiera färdiga videor innan resurserna löper ut. Vid migrering av en Sora-app måste indatareferenser vanligtvis laddas upp eller formateras om för målleverantören, medan genererade video-URL:er bör behandlas som tillfälliga hämtningsplatser. Placera båda bakom ett tillgångslager som äger beständiga filer, checksummor, åtkomstpolicy och leverantörsmappningar. En API-kompatibel begärandeform gör inte fil-ID:n eller utdatalänkar portabla. Resurserna tillhör normalt leverantören som utfärdade dem. ## Separera tillgångar från leverantörsreferenser Använd applikationens tillgångs-ID som stabil nyckel: ```json { "asset_id": "asset_01J...", "kind": "input_image", "sha256": "...", "storage_key": "inputs/asset_01J...png", "provider_refs": { "openai": "provider-specific-reference" } } ``` Källfilens ID, videojubbets ID och den signerade utdata-URL:en är attribut på posten, inte identifierare i produktens permanenta kontrakt. ## Återskapa indatareferenser OpenAI:s video-endpoint accepterar en prompt och kan ta en valfri `input_reference`-bild. Måltjänsten kan kräva multipart-upload, ett föruppladdat file ID, en offentlig URL eller base64-data. Läs varje original från beständig lagring, validera medietyp och dimensioner och skapa målreferensen. Anta inte att ett OpenAI-fil- eller media-ID kan skickas till en annan leverantör. Om appen bara lagrade leverantörsreferensen, kontrollera om originalet fortfarande kan hämtas. Utgångna eller raderade indata kräver ny uppladdning; ingen identifierarkonvertering kan återskapa saknade bytes. ## Mappa jobbobjekt uttryckligen Soras videogenerering är asynkron. Jobbet har ID, status, framsteg, modell, längd, storlek, tidsstämplar och ibland utgångstid. Lagra måljobbet bredvid källjobbet: | Applikationsfält | Källmappning | Målmappning | |---|---|---| | Internt jobb-ID | Din databas | Samma värde | | Leverantörens jobb-ID | OpenAI video-ID | Målets jobb-ID | | Status | Källstatus | Normaliserad målstatus | | Indatatillgång | Källreferens | Återuppladdad målreferens | | Utdatatillgång | Hämtade bytes | Hämtade målbytes | Skriv aldrig över källmappningen under en stegvis migrering. Båda behövs för återställning och supportutredningar. ## Hämta utdatan, inte bara URL:en OpenAI API har en innehålls-endpoint för slutförda videojubb och rapporterar `expires_at` när tillgångar löper ut. En URL från ett svar kan sluta fungera, kräva autentisering eller vara olämplig för klienter. När jobbet slutförs bör workern: 1. hämta videon från den autentiserade endpointen; 2. strömma den till applikationsägd objektlagring; 3. verifiera medietyp, filstorlek och checksumma; 4. registrera proveniens, modell, promptpolicy och parametrar; 5. leverera via en egen auktoriserad URL. Använd samma process för miniatyrer, förhandsvisningar och andra varianter som produkten behöver. ## Planera lagringstid och integritet Kopiering ändrar datastyrningen. Definiera separat lagringstid för användaruppladdningar, mellanprodukter, slutvideor, miniatyrer och misslyckade jobb. Kryptera tillgångar, begränsa tjänsteroller och logga inte signerade URL:er eller råa promptar. Vid radering, ta bort applikationens kopia och anropa leverantörens raderings-endpoint när den finns. Behåll en raderingstombstone med okänsliga ID:n så att omförsök är idempotenta. ## Testa mediebeteende före övergång Bygg fixtures för format, orientering, upplösning, längd och maximal storlek. Kontrollera alfakanaler och färgprofiler när de spelar roll. Testa utgångna länkar, partiella hämtningar, fel content-type, range requests, avbrott och omförsök efter worker-krasch. Jämför mediepolicy och moderering, inte bara API-mekanik. En syntaktiskt accepterad begäran kan ändå ge olika tillåtet innehåll eller resultategenskaper. ## Slutsats Soras filreferenser och utdata-URL:er är leverantörsresurser, inte portabla tillgångar. Bevara originalbytes, skapa nya målreferenser, hämta färdiga videor direkt och exponera stabila applikations-ID:n. Då kan migreringen återställas och utgångna länkar orsakar inte dataförlust. ## FAQ ### Kan OpenAI input_reference skickas till en annan videoleverantör? Vanligen inte. Läs originalfilen från din lagring och skapa multipart-upload, file ID, URL eller base64-referens enligt målets krav. ### Är Soras utdata-URL:er permanenta? Behandla dem som tillfälliga eller autentiserade leveransplatser. Jobbet kan ange en utgångstid, så hämta innehållet omgående till egen lagring. ### Vad händer om bara leverantörens fil-ID sparats? Försök hämta originalbytes medan resursen finns kvar. Om den löpt ut eller raderats kan användaren behöva ladda upp originalfilen igen. ### Vilket ID bör appen visa? Visa egna stabila tillgångs- och jobb-ID:n. Behåll källans och målets leverantörs-ID:n som mappningar för hämtning, support och återställning. ### Bör källmappningen skrivas över efter migreringen? Nej. Behåll båda mappningarna under en stegvis migrering så att beteenden kan jämföras och återställning förblir säker. ### Vad bör testas för videotillgångar? Testa format, storlekar, längder, orienteringar och varianter samt utgång, partiella hämtningar, avbrott och omförsök av lagring.