Wer nach „Midjourney API Fehler“ sucht, findet in der Regel keine offizielle Fehlercode-Tabelle. Midjourney hat keine allgemeine öffentliche API; aufgerufen werden meist Drittanbieter-Wrapper oder Relay-Gateways, deren Statuscodes, Fehlerfelder und Wiederholungsregeln der Anbieter festlegt. Derselbe 401 kann bei zwei Plattformen unterschiedliche Ursachen haben.

Dieser Beitrag ordnet häufige Störungen nach HTTP-Semantik und Aufgabenlebenszyklus, gibt eine Diagnosereihenfolge, Muster für Wiederholung und Idempotenz sowie eine Checkliste für Support-Tickets. Schnittstellen, Fehlercodes und Abrechnung richten sich nach der Anbieterdokumentation.

Hinweis: Midjourney ist eine Marke von Midjourney, Inc.; Discord ist eine Marke von Discord Inc. Die hier besprochenen Wrapper- und Relay-Dienste stehen in keiner Beziehung zu den genannten Unternehmen; Schnittstellen, Fehlercodes und Abrechnung richten sich nach der Anbieterdokumentation.

1. Zuerst bestimmen, auf welcher Ebene der Fehler auftritt

Ein Aufruf durchläuft fünf Ebenen: Client und Netzwerk, Gateway-Authentifizierung, Upstream-Kontopool, Generierungsaufgabe sowie Ergebnisspeicher und CDN. Störungen zeigen sich unterschiedlich:

Symptom Mögliche Ebene Erster Schritt
Alle Schnittstellen schlagen fehl Client, Netzwerk, DNS, Proxy Netz wechseln oder mit minimaler Anfrage reproduzieren
Nur Midjourney schlägt fehl Kanal oder Upstream-Kontopool Statusseite des Anbieters und andere Modelle prüfen
4xx beim Senden Authentifizierung, Parameter, Ratenlimit Anfrage anhand des Fehlercodes prüfen
Senden erfolgreich, Aufgabe fehlgeschlagen Generierung, Moderation, Upstream-Konto Fehlerfeld der Aufgabe lesen
Aufgabe erfolgreich, Bild nicht abrufbar Ergebnislink, CDN, Download Gültigkeit des Links prüfen und Download wiederholen

Bei der Suche zuerst drei Fragen beantworten: Scheitert alles oder nur ein Teil? Scheitert das Senden oder die Aufgabe? Tritt es reproduzierbar oder zu Spitzenzeiten auf? Diese drei Antworten halbieren den Suchraum.

2. 401 und 403: Authentifizierung, Rechte und Kontostatus

401 bedeutet, dass die Identität nicht anerkannt wurde. Häufige Ursachen: fehlender oder falsch geschriebener Header, Leerzeichen im Key oder bereits rotierter Key, Web-Cookie oder temporäres Token als API-Key verwendet, falsche Base URL oder eine zu stark abweichende Systemzeit, die Signaturen ungültig macht.

403 bedeutet, dass die Identität erkannt, der Zugriff aber nicht erlaubt ist. Häufige Ursachen: Key nicht für das Modell freigeschaltet, IP nicht auf der Whitelist, Region eingeschränkt, Tarif abgelaufen, Konto unter Risikokontrolle oder unzureichende Workspace-Rechte.

Vorgehen:

  1. Mit einer minimalen Anfrage reproduzieren, nur Auth-Header und Pflichtfelder behalten.
  2. Anhand der Dokumentation Header-Name und Präfix prüfen, besonders das Leerzeichen nach Bearer.
  3. In der Konsole Key-Status, Modellrechte, Guthaben und Ablaufdatum prüfen.
  4. Einen neuen Test-Key verwenden; bei weiterhin 403 beim Anbieter IP, Region und Kontopoolstatus klären.

Keys gehören nicht in Frontend-Code oder öffentliche Repositories. Bei 401 zuerst die Konfiguration verdächtigen und nicht wiederholt senden; Wiederholungen machen einen falschen Key nicht richtig.

3. 429: Ratenlimit, Parallelität und Kontingent

429 bedeutet mehr, als viele annehmen. Es kann die Anfragen pro Minute, gleichzeitig laufende Aufgaben, das Tageskontingent, einen vorübergehend leeren Kontopool oder eine Upstream-Warteschlange anzeigen. Die Behandlung unterscheidet sich grundlegend.

Zuerst Response-Header und Fehlerkörper lesen: Gibt es Retry-After, entsprechend warten; nennt die Meldung quota oder balance, ist meist das Kontingent gemeint; steht dort concurrency oder queue, ist es ein Parallelitätsproblem; sind alle Keys gleichzeitig von 429 betroffen, kann der Kontopool des Anbieters angespannt sein.

Gegenmaßnahmen:

  • Clientseitige Warteschlange und Parallelitätslimit, nicht in Spitzen alles gleichzeitig senden.
  • Exponentielles Backoff mit zufälligem Jitter, damit nicht alle zur selben Zeit wiederholen.
  • Unterscheiden zwischen „erholt sich nach kurzer Zeit“ und „Guthaben aufladen oder Limit erhöhen“.
  • Modell, Zeitfenster und Anfragevolumen der 429er protokollieren, um eigenen Verkehr von Upstream-Kapazität zu trennen.

429 löst sich nicht durch mehr Versuche; blindes Wiederholen verlängert die Warteschlange und kann eine Sperre verlängern.

4. Abgelehnter Prompt: Moderation und Parameterfehler

„Prompt abgelehnt“ hat zwei Ursachenklassen. Erstens Inhaltsmoderation: Gewalt, sexuelle Inhalte, Minderjährige, reale Prominente, urheberrechtlich geschützte Figuren, Marken oder Politiker können auslösen. Zweitens Parameterfehler: nicht unterstütztes Seitenverhältnis, nicht existierende Modellversion, zu langer Prompt, nicht erreichbare Referenzbild-URL oder nicht unterstütztes Format.

Beide sollten nicht unverändert wiederholt werden. Bei Moderationsablehnung Material und Formulierung anpassen und nicht mit Synonymen, Zeichenzerlegung oder Andeutungen wiederholt umgehen; bei Parameterfehlern die Felder nach Dokumentation korrigieren. Abgelehnte Prompts, Modellversion und Response-Body dokumentieren und zu einer teaminternen Sperrliste und Prüfregel ausbauen.

Außerdem zwischen „abgelehnt“ und „fehlgeschlagen“ unterscheiden: Ersteres geschieht meist vor der Generierung, Letzteres kann bereits Kosten verursacht haben; maßgeblich sind die Anbieterregeln.

5. Aufgabenfehler, Timeouts und abgelaufene Ergebnisse

Aufgabenfehler können durch interne Upstream-Fehler, Kontoanomalien, ungültige Parameter, fehlgeschlagenen Download des Referenzbilds, Moderationsabbruch und Warteschlangen-Timeout entstehen. Zuerst das Fehlerfeld lesen, nicht nur „failed“.

Timeouts sind in drei Arten zu trennen: Client-Lese-Timeout, bei dem die Anfrage bereits beim Server angekommen sein kann; Sende-Timeout, bei dem die Aufgabe erstellt sein kann, aber die Antwort ausblieb; Polling-Timeout, bei dem die Aufgabe noch läuft, das Wartefenster aber endet.

Am gefährlichsten ist sofortiges erneutes Senden nach einem Sende-Timeout, weil die ursprüngliche Aufgabe bereits existieren kann – die Folge ist doppelte Abbuchung. Richtig ist: beim Senden einen Idempotenzschlüssel oder eine Geschäftsanfragenummer mitgeben; nach Timeout zuerst nach der Anfragenummer die letzten Aufgaben suchen; erst nach Bestätigung, dass keine existiert, wiederholen. Unterstützt der Anbieter keine Idempotenzschlüssel, in der Aufgabentabelle ein Deduplizierungsfenster führen.

Abgelaufene Ergebnisse sind eine eigene Klasse. Erfolgreiche Antworten enthalten oft temporäre URLs mit Gültigkeit von Minuten bis Tagen, die nicht als dauerhafte Werksadresse gespeichert werden dürfen. Nach Erfolg sofort in den Objektspeicher übertragen; die Datenbank behält nur den eigenen Speicherpfad und die Aufgaben-ID.

6. Download-Fehler: 403, 404 und abgeschnittene Dateien

Ein Download-Fehler ist nicht gleich ein Generierungsfehler. Häufig: Signed URL abgelaufen und 403; Aufgabenergebnis bereinigt und 404; Proxy- oder Netzabbruch mit Verbindungsreset; HTML-Fehlerseite als Bild gespeichert; Datei nur halb geladen.

Downloads brauchen eine eigene Logik: Content-Type und Dateigröße prüfen; zuerst in eine temporäre Datei schreiben und nach Erfolg atomar umbenennen; bei 5xx und Netzwerkfehlern wiederholen; bei 403 und 404 nicht die Generierung wiederholen, sondern den Aufgabenstatus prüfen, ob das Ergebnis noch existiert. Bietet der Anbieter mehrere Ergebnisadressen, eine Ersatz-Domain oder einen alternativen Übertragungsweg vorbereiten.

7. Wiederholung und Idempotenz: Fehler dürfen nicht doppelt kosten

Das Prinzip ist Klassifizierung, nicht eine einheitliche Schleife. 401, 403, 400, 422 und Moderationsablehnung nicht wiederholen, bevor Konfiguration oder Prompt korrigiert sind; 429 nach Retry-After warten; 5xx, Verbindungsreset und Lese-Timeout mit Backoff wiederholen; nach Sende-Timeout zuerst die Aufgabe prüfen.

import random
import time
import requests

RETRYABLE = {429, 500, 502, 503, 504}

def post_with_retry(url, headers, payload, request_id, max_attempts=4):
    for attempt in range(1, max_attempts + 1):
        try:
            resp = requests.post(
                url,
                headers={**headers, "Idempotency-Key": request_id},
                json=payload,
                timeout=(10, 60),
            )
        except (requests.Timeout, requests.ConnectionError):
            if attempt == max_attempts:
                raise
            time.sleep(min(2 ** attempt + random.random(), 30))
            continue

        if resp.status_code in RETRYABLE:
            retry_after = resp.headers.get("Retry-After", "")
            wait = int(retry_after) if retry_after.isdigit() else 2 ** attempt
            time.sleep(min(wait + random.random(), 60))
            continue

        if resp.status_code >= 400:
            raise RuntimeError(f"{resp.status_code}: {resp.text[:200]}")
        return resp.json()

    raise RuntimeError("Wiederholungsbudget ausgeschöpft")

Das Idempotency-Key im Beispiel ist eine verbreitete Form; ob und mit welchem Feldnamen sie unterstützt wird, steht in der Anbieterdokumentation. Ohne Idempotenzschlüssel lässt sich dasselbe Ziel mit Geschäftsanfragenummer und Deduplizierung in der Aufgabentabelle erreichen.

8. Checkliste vor dem Support-Ticket

  1. Zeitpunkt, Zeitzone und Dauer erfassen.
  2. Request-ID, Aufgaben-ID und Geschäftsnummer beifügen.
  3. Schnittstellenadresse, Modellname und Schnittstellenversion angeben.
  4. Vollständigen HTTP-Status und Response-Body beifügen; Key und personenbezogene Daten maskieren.
  5. Anfrageparameter, Anzahl der Referenzbilder und Seitenverhältnis nennen, nicht nur „Generierung fehlgeschlagen“.
  6. Anzahl und Abstand der Wiederholungen, Netzwerkumgebung und Ausgangsregion dokumentieren.
  7. Minimale Reproduktionsschritte und Ergebnisse mit demselben Parametersatz bei einem anderen Modell liefern.
  8. Auswirkung beschreiben: wie viele Aufgaben fehlgeschlagen sind, ob die Produktion betroffen ist.

Die nützlichsten Angaben im Ticket sind konkretes Modell, Region, Zeitfenster, Parameter und drei Request-IDs – nicht „die Schnittstelle funktioniert nicht“.

9. Monitoring und Vorbeugung

Fehler zu Kennzahlen machen: 401, 403, 429, 5xx, Aufgabenfehler, Timeouts und Download-Fehler je Modell zählen; P95-Dauer erfassen; täglich prüfen, ob fehlgeschlagene Aufgaben berechnet wurden. Schwellenalarme für 429, Aufgabenfehlerquote und Download-Fehlerquote einrichten, statt auf Beschwerden zu warten.

Im Alltag vorbeugen: Keys nach Umgebung und Projekt trennen, Test-Keys mit Kontingentlimit versehen, Parallelität begrenzen, maximale Wiederholungen und Dead-Letter-Queue pro Aufgabentyp setzen. Bei Drittanbieter-Wrappern Statusseite, Reaktionszeit und Ausfallplan prüfen und nicht den gesamten Verkehr auf einen Kanal ohne SLA legen.

Häufige Fragen

401 bleibt auch nach Key-Wechsel?

Zuerst prüfen, ob der neue Key aktiv und für das Modell berechtigt ist, dann Header-Präfix, Base URL und Systemzeit. Funktionieren andere Modelle, kann der Upstream-Kontopool die Ursache sein.

Ist 429 ein Zeichen für zu wenig Guthaben?

Nicht unbedingt. 429 kann Anfragefrequenz, Parallelität, Kontingent oder Kontopool-Kapazität bedeuten. Zuerst Header und Fehlerkörper lesen; erst bei quota oder balance liegt eher ein Guthabenproblem vor.

Kann man nach einem Aufgaben-Timeout direkt neu senden?

Nicht empfehlenswert. Ein Sende-Timeout heißt nicht, dass keine Aufgabe erstellt wurde; direktes Neusenden kann doppelt abbuchen. Zuerst über Anfragenummer oder Aufgaben-ID abfragen und erst bei Bestätigung wiederholen; beim Senden möglichst einen Idempotenzschlüssel mitgeben.

Das hängt davon ab, ob der Anbieter Ergebnisse vorhält. Zuerst den Aufgabenstatus prüfen; wurde bereinigt, bleibt meist nur eine Neugenerierung. In der Produktion nach Erfolg sofort persistieren und nicht von temporären Links abhängen.

Bearbeitet Midjourney offiziell Fehler von Drittanbieter-Schnittstellen?

Nein. Drittanbieter-Wrapper stehen in keiner Beziehung zu Midjourney; Fehler muss der Anbieter untersuchen. Midjourney unterhält auch keinen offiziellen API-Supportkanal.

Nächster Schritt

Ordnen Sie Fehler zuerst in die fünf Klassen Authentifizierung, Ratenlimit, Inhalt, Aufgabe und Download ein und entscheiden Sie dann, was wiederholt und was alarmiert wird. Für einen einheitlichen Eingang können Sie im ZSQH AI Gateway einen Key anlegen und auf der Seite Modellpreise Modelle und Abrechnung prüfen.

Weitere Beiträge: