AI-API wird abgeschaltet: Migrationsaudit vor dem Stichtag

Ein neuer Modelname oder eine Base URL ist keine Migration: Streaming, Tools, Fehler, Limits und Usage können abweichen. Erforderlich sind Shutdown-Datum aus der Primärquelle, vollständiges Inventar, Vertragsvergleich und reversibler Cutover. Am 25.08.2026 veröffentlicht OpenAI Datum und Ersatz in Deprecations; die allgemeine Policy nennt sechs Monate für generally available, drei für spezialisierte Varianten und weniger für preview. Maßgeblich ist der konkrete Eintrag.

1. Ereignis erfassen

Vor Codeänderungen Quelle, Prüftag, alten/neuen Endpoint und Model, shutdown_date und Owner notieren. Das Datum nur aus dem Anbieterhinweis übernehmen; sonst unknown schreiben, Neuprüfung zuweisen und keine Dringlichkeit erfinden.

deprecation_source: https://developers.openai.com/api/docs/deprecations
checked_at: 2026-08-25
old_endpoint: /v1/chat/completions
old_model: OLD_MODEL_ID
replacement_endpoint: /v1/chat/completions
replacement_model: NEW_MODEL_ID
shutdown_date: YYYY-MM-DD
owner: team-name

2. Abhängigkeiten inventarisieren

Endpoint, Base URL, Protokoll, ID/Fallback, Payload/Messages, Tool-Schema/Fields/Choice, SSE-Parser/Usage, Fehler/Retry, Prompt, Services, Cron, Workflows, SDK, CI, Serverless, n8n/Dify, Secret Store und Jobs erfassen. Nur Secret-Namen und Owner speichern, nie Werte.

3. Kontrollanfragen bauen

Bereinigte echte Fälle nutzen: Fakten-Text, Pflichtfeld-JSON, gültiger Tool Call, No-Tool, beendeter Stream, 4xx und temporärer Fehler/Test Double. Schema, Argumente, Ergebnis, Fakten, Stream-Ende und Retry vergleichen, nicht Wortlaut; Kosten und Latency separat messen.

4. Streaming und Fehler separat prüfen

Event und data, Ende, Usage, Abbruch vor/nach erstem Token und doppelte externe Aktion festhalten. HTTP status, machine-readable Code und Retry-Grenze bewahren. 401, 403 und schema validation error nicht automatisch wiederholen; bei 429/temporärem 5xx Retry-After beachten, Versuche begrenzen und idempotency nutzen.

5. Beide Pfade doppelt ausführen

Alt ist im Test baseline, neu erhält dieselben Fixtures. Speichern:

case_id | old_result | new_result | contract_pass | difference | decision

Geänderte Argumente, Fields, Stream-Ende oder Fehler verlangen Fix oder ausdrückliche Akzeptanz.

Mit BetterToken https://www.bettertoken.ai/v1/chat/completions, Bearer Key und aktuelle Model ID verwenden. Eine test Key erstellen, die Kontrollanfrage nach dem aktuellen Chat-Completions-Vertrag ausführen und HTTP status sowie ein prüfbares response field erfassen: Format, nicht Model-Äquivalenz.

Vor dem Cutover die Fields mit dem aktuellen Vertrag abgleichen. Chat-Completions-Anleitung öffnen

6. Reversibel umschalten

Feature Flag/versionierte Config, Owner/Fenster, Metriken, genaue Rollback-Bedingung und alte Config ohne Secrets vorbereiten. Beide Verträge deployen, kontrolliert starten, vergleichen, nur bei Kriterien erweitern, bei geschriebenem Invariant zurückrollen und alt erst nach Beobachtung vor Shutdown entfernen. Zeit für Fix und Wiederholung lassen: Rollback stellt eine abgeschaltete API nicht wieder her.

Nachweise

Quelle/Datum, Inventar mit Ownern, versionierte Fixtures/Ergebnisse, Entscheidung je Differenz und messbares Runbook sind Pflicht. Ohne eines bleibt migration_in_progress, auch bei 200.

Quellen: https://developers.openai.com/api/docs/deprecations und https://docs.bettertoken.ai/api-reference/chat-completions.