OpenAI plant die Einstellung der Sora-API für den 24. September 2026: Was Teams jetzt prüfen sollten

Der angekündigte Termin und die betroffenen Komponenten

In der OpenAI-Dokumentation zu eingestellten Funktionen ist der 24. September 2026 als Termin für die Einstellung der Videos API sowie der Modelle sora-2 und sora-2-pro und der auf der Seite aufgeführten Snapshots angegeben. In der Spalte für einen Ersatz ist keine Alternative genannt. Auf Grundlage der vorliegenden offiziellen Informationen sollten Teams daher weder mit einer automatischen Migration noch mit einer Fristverlängerung oder einem kompatiblen Ersatzmodell planen.

Bei dem genannten Datum handelt es sich um einen veröffentlichten Zeitplan. Es bestätigt weder, dass der Dienst bereits abgeschaltet wurde, noch, wie genau er sich an diesem Tag verhalten wird. Derzeit beschreibt der Leitfaden zur Videogenerierung einen Ablauf, bei dem Jobs asynchron erstellt, ihr Status abgefragt und die fertige Datei heruntergeladen wird. Die Referenz für das Abrufen eines Videos beschreibt außerdem Job-Metadaten, darunter das Feld expires_at für herunterladbare Assets. Keine dieser Beschreibungen erklärt, was nach dem Einstellungstermin mit Anfragen, laufenden Jobs oder Metadaten geschieht.

Für die praktische Planung sollten Teams zwei Aufgaben auseinanderhalten: die Kontinuität des eigenen Produkts vorzubereiten und bereits verfügbare eigene Assets zu sichern. Ein heruntergeladenes Video zu speichern, kann diese Datei bewahren. Dadurch bleibt jedoch nicht automatisch die Fähigkeit erhalten, über die Integration weitere Videos zu generieren. Umgekehrt belegt ein gespeicherter Verweis oder eine Job-ID in der Anwendung nicht, dass das zugehörige Asset weiterhin abgerufen werden kann.

API nicht mit App oder Website gleichsetzen

Die Videos API ist eine Schnittstelle, über die Anwendungen und Arbeitsabläufe Videos programmatisch generieren und abrufen können. Der technische Leitfaden beschreibt das Erstellen eines Jobs, die Abfrage seines Status und den Download seines Inhalts. So lassen sich konkrete Software-Abhängigkeiten erkennen: API-Aufrufe, die Verarbeitung ihrer Antworten und Komponenten, die ein Video oder dessen Metadaten erwarten.

Die Einstellung einer API sollte nicht automatisch als Schließung einer Anwendung oder einer Website für Nutzerinnen und Nutzer beschrieben werden. Es handelt sich um unterschiedliche Zugangskanäle, für die jeweils andere Zeitpläne, Bedingungen und Exportwerkzeuge gelten können. Die für diesen Beitrag geprüften Quellen dokumentieren jedoch die API und legen nicht fest, wann die Sora-App und die Sora-Website geschlossen wurden oder ob sie geschlossen wurden. Sie enthalten auch keine Export- oder Löschanweisungen für diese Produkte. Deshalb lässt sich aus Exportinformationen zur App nicht ableiten, was mit Daten oder Assets geschieht, die über die API erstellt wurden.

Diese Unterscheidung ist wichtig für Teams, die mehrere Zugangskanäle verwenden. Eine über die API heruntergeladene Videobibliothek, ein Nutzerkonto in einer Anwendung und ein über die API angebundenes Produktionssystem können unterschiedliche Assets und Abhängigkeiten umfassen. Für jeden Kanal müssen die jeweiligen offiziellen Anweisungen geprüft werden. Die verfügbaren Quellen erlauben es nicht, all diese Fälle einer einheitlichen Aufbewahrungsregel zu unterstellen.

Was Teams vor dem Termin in ihren Integrationen prüfen sollten

Der erste Schritt ist, sämtliche Abhängigkeiten zu finden – nicht nur die Stelle, an der eine Generierung angefordert wird. Im technischen Leitfaden verwendet der Aufruf zum Erstellen eines Videos POST /videos. Der Status wird mit GET /videos/{video_id} abgefragt; der Abruf der Datei erfolgt über GET /videos/{video_id}/content. Diese Bezeichnungen können bei der Suche in Code, Konfigurationen, Protokollen, geplanten Jobs und Drittanbieterdiensten helfen, die einen direkten API-Aufruf möglicherweise verbergen.

Anschließend sollten Teams dokumentieren, welche Produktbereiche von den einzelnen Vorgängen abhängen. So könnte eine Anfrage einen Bearbeitungsablauf anstoßen, auf den Abschluss eines Jobs warten und die Datei dann in einen Speicher- oder Prüfprozess weiterleiten. Wenn ein Aufruf nicht mehr verfügbar ist, kann sich der Fehler auf nachgelagerte Komponenten auswirken. Die bereitgestellte Dokumentation nennt allerdings weder den HTTP-Statuscode noch das genaue Verhalten des Dienstes nach der Abschaltung. Sinnvoll ist deshalb, die Fehlerbehandlung zu testen und einen kontrollierten Rückfallmodus vorzusehen, statt vorab zu behaupten, wie der Anbieter reagieren wird.

Außerdem sollten Teams zwischen Assets unterscheiden, die bereits in ihrem eigenen Speicher liegen, und solchen, die nur über die API abgerufen werden können. Für jedes heruntergeladene Video können sie die Datei und die Metadaten aufbewahren, die zur Identifizierung und Nutzung erforderlich sind – vorbehaltlich ihrer internen Anforderungen und der geltenden Rechte. Für Assets, die noch von einem späteren Abruf abhängen, garantiert die geprüfte Dokumentation nicht, dass dieser nach dem angekündigten Termin möglich bleibt.

Beispiel: Bestandsaufnahme und betriebliche Reaktion

Angenommen, ein interner Dienst nimmt Videoanfragen entgegen, speichert die Job-ID, fragt regelmäßig den Status ab und lädt nach Abschluss den Inhalt herunter, um ihn an ein Prüfsystem weiterzugeben. Die Bestandsaufnahme sollte jeden Vorgang und jedes nachgelagerte Ziel getrennt erfassen. So wird sichtbar, ob das Team von der Erstellung neuer Videos, der Abfrage bereits gestarteter Jobs, dem Herunterladen von Dateien oder von allen drei Vorgängen abhängig ist.

Wenn das Team nur die Job-ID aufbewahrt, besitzt es damit nicht notwendigerweise eine lokale Kopie des Videos. Wird die heruntergeladene Datei gespeichert, kann dieses Asset im eigenen Speicher gesichert werden. Das bedeutet aber weder, dass die Generierung weiter verfügbar ist, noch lässt sich daraus ableiten, wie lange Metadaten im Dienst zugänglich bleiben. Die Referenz führt expires_at als Metadatum zu herunterladbaren Assets auf; sie erklärt nicht, wie dieses Feld nach der Einstellung zu behandeln ist.

Ein kontrollierter Abschalttest könnte in einer Testumgebung fehlerhafte Antworten oder eine Nichtverfügbarkeit simulieren. Dabei lässt sich prüfen, ob eine Warteschlange Anfragen nicht unbegrenzt wiederholt, ob Nutzende einen verständlichen Status erhalten und ob nachgelagerte Prozesse einen Job nicht ohne Datei als abgeschlossen markieren. Das ist eine Empfehlung für die technische Planung, keine Vorhersage zur konkreten Antwort der API. Die bereitgestellte Dokumentation spezifiziert diese Antwort nicht.

Eine Migration ist weiterhin nicht spezifiziert

Die Tabelle zu den eingestellten Funktionen nennt für die aufgeführten Komponenten keinen Ersatz. Das beweist nicht, dass es keine anderen Tools zur Videogenerierung gibt. Mit den geprüften Quellen lässt sich jedoch kein Ersatz als offizielle oder kompatible Migration empfehlen. Vor der Auswahl einer anderen Lösung sollten Verantwortliche prüfen, welche Vorgänge sie unterstützt, wie sie Jobs verwaltet, welche Formate sie erzeugt und welche Bedingungen gelten. Ebenso ist zu klären, ob sie die Anforderungen an Sicherheit, Kosten, Qualität und Integration erfüllt.

Aus diesen Quellen lässt sich auch nicht ableiten, was mit noch laufenden Jobs am 24. September 2026 geschieht, ob Metadaten weiterhin sichtbar bleiben oder wie lange das der Fall wäre. Ebenso wenig ist bekannt, ob es Ausnahmen oder spätere Änderungen am Zeitplan gibt. Die technische Referenz nennt den geplanten Termin, beschreibt aber nicht die betrieblichen Folgen an diesem Tag. Falls OpenAI Aktualisierungen veröffentlicht, sollten diese Anweisungen geprüft werden, bevor unumkehrbare Entscheidungen getroffen werden.

Bei betrieblichen Entscheidungen ist es sinnvoll, zwischen dem zu unterscheiden, was ein Team selbst steuern kann, und dem, was vom Anbieter abhängt. Das Team kann Aufrufe finden, neue Abhängigkeiten reduzieren, bereits verfügbare Assets sichern, eigene Metadaten dokumentieren und das Verhalten seiner Systeme bei Fehlern testen. Aus diesen Maßnahmen lässt sich jedoch weder die weitere Verfügbarkeit des Endpunkts noch die Aufbewahrung entfernter Assets oder eine Fristverlängerung ableiten. Für jede Aufgabe sollten Verantwortliche und interne Termine festgelegt werden; außerdem sollte die offizielle Dokumentation kurz vor der Änderung erneut geprüft werden.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.