OpenAI programma il ritiro dell’API di Sora per il 24 settembre 2026: cosa devono verificare i team

La data annunciata e i componenti interessati

La documentazione di OpenAI sulle dismissioni fissa al 24 settembre 2026 il ritiro di Videos API e dei modelli sora-2 e sora-2-pro, oltre che degli snapshot elencati nella stessa pagina. Nella colonna dedicata al sostituto non compare alcuna alternativa. Sulla base delle informazioni ufficiali disponibili, quindi, i team non dovrebbero pianificare dando per scontati una migrazione automatica, una proroga o un modello sostitutivo compatibile.

La data indicata è una scadenza pubblicata, non la conferma che il servizio sia già stato disattivato, né una descrizione di come si comporterà esattamente in quel momento. La guida alla generazione video documenta attualmente un flusso in cui si creano lavori in modo asincrono, se ne controlla lo stato e si scarica il file risultante. Anche il riferimento per il recupero descrive i metadati del lavoro, incluso il campo expires_at per gli asset scaricabili. Nessuna di queste descrizioni spiega che cosa accadrà a richieste, lavori in corso o metadati una volta raggiunta la data di ritiro.

Dal punto di vista pratico, occorre distinguere due attività: preparare la continuità del prodotto e preservare gli asset propri già disponibili. Salvare un video scaricato può conservarne il file, ma non mantiene di per sé la capacità di generare altri video tramite l’integrazione. Allo stesso modo, il fatto che un’applicazione conservi un riferimento o un identificativo del lavoro non dimostra che l’asset resterà recuperabile.

Non confondere l’API con l’app o il sito web

Videos API è un’interfaccia che consente alle applicazioni e ai flussi di lavoro di effettuare operazioni programmatiche di generazione e recupero dei video. La guida tecnica descrive la creazione di un lavoro, il controllo del suo stato e il download dei contenuti. Questo permette di individuare dipendenze software concrete: chiamate all’API, elaborazione delle risposte e componenti che si aspettano di ricevere un video o di consultarne i metadati.

Il ritiro di un’API non va descritto automaticamente come la chiusura di un’app o di un sito web destinati agli utenti. Si tratta di canali diversi, che possono avere calendari, condizioni e strumenti di esportazione distinti. Tuttavia, le fonti verificate per questa nota documentano l’API e non stabiliscono quando l’app e il sito web di Sora abbiano chiuso, né se lo abbiano fatto. Non forniscono neppure istruzioni di esportazione o cancellazione per quei prodotti. Perciò non è possibile usare qui informazioni sull’esportazione dall’app per dedurre che cosa accadrà ai dati o agli asset creati tramite API.

La distinzione è importante per i team che usano più di un canale. Una libreria di video scaricati tramite API, un account utente nell’app e un sistema di produzione collegato via API possono coinvolgere asset e dipendenze differenti. Per ciascun canale occorre verificare le relative istruzioni ufficiali; le fonti disponibili non consentono di ricondurre tutti questi casi a un’unica politica di conservazione.

Cosa verificare in un’integrazione prima della data

Il primo passo è individuare tutte le dipendenze, non soltanto il punto in cui viene richiesta una generazione. Nella guida tecnica, l’operazione di creazione utilizza POST /videos; il controllo dello stato usa GET /videos/{video_id}, mentre il recupero del file avviene tramite GET /videos/{video_id}/content. Questi nomi possono aiutare nelle ricerche nel codice, nelle configurazioni, nei log, nei processi pianificati e nei servizi di terze parti che potrebbero nascondere la chiamata diretta.

Poi conviene documentare quali parti del prodotto dipendono da ciascuna operazione. Per esempio, una richiesta può avviare un processo di montaggio, attendere il completamento di un lavoro e inviare il file a un sistema di archiviazione o revisione. Se una chiamata non fosse più disponibile, il problema potrebbe propagarsi ai componenti successivi, anche se la documentazione disponibile non specifica il codice di risposta né il comportamento del servizio dopo la disattivazione. La risposta appropriata è verificare la gestione degli errori e progettare una modalità di degrado controllata, non affermare in anticipo come risponderà il fornitore.

I team dovrebbero anche distinguere gli asset già presenti nel proprio spazio di archiviazione da quelli recuperabili soltanto tramite API. Per ogni video scaricato possono conservare il file e i metadati necessari a identificarne l’uso, nel rispetto dei requisiti interni e dei diritti applicabili. Per gli asset che dipendono ancora da un’operazione di recupero, la documentazione esaminata non garantisce che tale operazione resterà disponibile dopo la data indicata.

Esempio di inventario e risposta operativa

Immaginiamo che un servizio interno riceva richieste di video, registri l’identificativo del lavoro, ne controlli periodicamente lo stato e, al termine, scarichi il contenuto per inviarlo a un sistema di revisione. Nell’inventario occorre registrare separatamente ogni operazione e ogni destinazione successiva. In questo modo si capirà se il team dipende dalla creazione di nuovi video, dal controllo dei lavori già avviati, dal download dei file o da tutte e tre le operazioni.

Se il team conserva soltanto l’identificativo del lavoro, non possiede necessariamente una copia locale del video. Se conserva il file scaricato, può preservare l’asset nel proprio spazio di archiviazione, ma ciò non equivale a mantenere attiva la generazione e non dimostra per quanto tempo i metadati resteranno disponibili nel servizio. Il riferimento include expires_at tra i dati associati agli asset scaricabili; la fonte non spiega come si applicherebbe questo campo dopo il ritiro.

Un test di disattivazione controllata potrebbe simulare risposte fallite o indisponibilità in un ambiente di prova e verificare che la coda non ripeta le richieste all’infinito, che gli utenti ricevano uno stato comprensibile e che i processi successivi non contrassegnino come completato un lavoro privo di file. È una raccomandazione ingegneristica, non una previsione sulla risposta specifica dell’API. La documentazione disponibile non specifica tale risposta.

La migrazione non è ancora specificata

La tabella delle dismissioni non indica un sostituto per i componenti segnalati. Questo non dimostra che non esistano altri strumenti di generazione video, ma significa che le fonti esaminate non offrono una base per raccomandare un’alternativa come migrazione ufficiale o compatibile. Prima di scegliere un’altra soluzione, i responsabili dovrebbero verificare quali operazioni offre, come gestisce i lavori, quali formati produce, quali condizioni applica e se soddisfa i requisiti di sicurezza, costo, qualità e integrazione.

Inoltre, da queste fonti non si può affermare che cosa accadrà ai lavori ancora in corso il 24 settembre 2026, se i metadati resteranno visibili o per quanto tempo, né se ci saranno eccezioni o modifiche successive al calendario. Il riferimento tecnico segnala la data prevista, ma non descrive le conseguenze operative di quel giorno. Se OpenAI pubblicherà aggiornamenti, sarà opportuno verificarli prima di prendere decisioni irreversibili.

Per prendere una decisione sul servizio, il criterio prudente consiste nel separare ciò che il team può controllare da ciò che dipende dal fornitore. Il team può individuare le chiamate, ridurre le nuove dipendenze, salvare gli asset già disponibili, registrare i propri metadati e verificare come reagiscono i sistemi agli errori. Non può dedurre da queste azioni che l’endpoint resterà attivo, che gli asset remoti saranno conservati o che ci sarà una proroga. È utile assegnare responsabili e scadenze interne a ogni attività e consultare la documentazione ufficiale in prossimità del cambiamento.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.