Midjourney-API über Relay: Tasks, Abrechnung, Migration (2026)

Midjourney hat keine allgemeine öffentliche API. Das bestimmt die tatsächliche Struktur von „Relay“ und „Proxy“: Es wird nicht einfach eine offizielle Schnittstelle unter einer anderen Domain angeboten, sondern auf einen Pool von Drittanbieter-Konten eine zusätzliche Schicht für Aufgabenorchestrierung und Abrechnung gelegt. Die Kette ist länger als bei Text-APIs, und es gibt mehr Stellen, an denen Fehler entstehen.

Dieser Beitrag beschreibt die reale Kette: Aufgabenstatus, Aufbewahrung der Ergebnisse, Abrechnungsabgleich, Key- und Kontorisiken, Anbieterbedingungen sowie Migration und Abnahme.

Hinweis: Midjourney ist eine Marke von Midjourney, Inc.; alle weiteren Produktnamen sind Marken ihrer Rechteinhaber. Dieser Beitrag dient der technischen Erläuterung; es besteht keine Zugehörigkeit oder Kooperation mit Midjourney. Schnittstellen, Status und Abrechnung von Relay-Diensten richten sich nach Anbieterdokumentation und Vertrag; dieser Beitrag ist keine Rechtsberatung.

1. Vier Arten von „Relay“ unterscheiden

Typ	Aufgabe	Hauptrisiko	Geeignetes Szenario
Kontopool-Proxy	Anbieter unterhält Midjourney-Konten und sendet automatisiert	Konto-Risikokontrolle, Warteschlange, Vertragsrisiko	Kleine und mittlere Teams, die eine API-Form brauchen
Aggregations-Gateway	Einheitlicher Eingang für mehrere Bildmodelle	Status-Mapping, Parameterunterschiede, Zwischenschichtfehler	Geschäft mit mehreren Modellen
Wiederverkauf/Aufladung	Weiterverkauf von Abos oder Kontingenten	Upstream-Stabilität, Guthaben und Erstattung	Kleine Tests, kurzfristiger Bedarf
Eigenbau-Automatisierung	Eigene Konten und Skripte	Betrieb, Kontosperren, volle Verantwortung	Technikteam mit Datenhoheit

Ob man „technische Dienstleistung“ oder „Modellkontingent“ kauft, entscheidet darüber, wer bei Problemen haftet. Vertrag, Rechnung und Datenbedingungen müssen mit dieser Unterscheidung geprüft werden.

2. Welche zusätzlichen Glieder die asynchrone Kette im Relay bekommt

Eine typische Kette: Der eigene Dienst sendet die Anfrage; das Relay prüft Authentifizierung, Ratenlimit und Abbuchung; es speichert die Zuordnung zwischen Geschäftsnummer und Upstream-Aufgaben-ID; der Kontopool stellt die Aufgabe in die Warteschlange und wartet auf die Generierung; das Relay pollt oder empfängt das Ergebnis und mappt den Status; schließlich wird das Bild persistiert oder ein temporärer Link durchgereicht.

Mit jedem zusätzlichen Sprung entsteht eine weitere Stelle, an der Status verloren gehen kann:

Das Relay startet neu oder wechselt die Instanz, und die Aufgaben-Zuordnung im Speicher geht verloren.
Der Upstream läuft in einen Timeout, die Aufgabe wurde aber bereits erstellt; das Relay meldet Fehler, der Aufrufer wiederholt und erhält zwei Bilder.
Eine Moderationsablehnung wird als normaler Fehler gemappt, und das Geschäft wiederholt endlos.
Der Ergebnislink läuft ab; die Aufgabe gilt als erfolgreich, der Download scheitert.
Ein Webhook ohne Idempotenzschlüssel führt zu doppelten Einträgen.

Bei der Bewertung nicht nur fragen „unterstützt es Midjourney?“, sondern wie Aufgaben-IDs persistiert, Status gemappt und Fehler kompensiert werden.

3. Aufgabenstatus und Aufbewahrung der Ergebnisse

Übliche Zustände sind Warteschlange, Generierung, Erfolg, Fehler, Moderationsablehnung sowie Timeout oder Ablauf. Der Name ist unwichtig; entscheidend ist die Zuordnung: Die Geschäftsseite muss „wiederholbar“ von „Wiederholung nutzlos“ unterscheiden können.

Moderationsablehnung, Parameterfehler und fehlendes Guthaben sollten nicht automatisch wiederholt werden; Timeouts und 5xx dürfen mit Backoff wiederholt werden; ein Erfolg mit Download-Fehler braucht eine eigene Kompensation. Jede Aufgabe braucht einen Idempotenzschlüssel, um doppelte Abbuchungen und doppelte Bilder zu vermeiden.

Bei der Aufbewahrung sind vier Fragen zu klären: Wie lange werden Aufgabendatensätze gespeichert; werden Bilder im Auftrag gespeichert und wo; wird ein temporärer Link oder eine dauerhafte Adresse zurückgegeben; lässt sich nach Ablauf noch über die Geschäftsnummer suchen? Bildlinks sind meist befristet, daher nach Erfolg sofort herunterladen und persistieren.

4. Wie man die Abrechnungstransparenz prüft

Bildaufgaben sind streitanfälliger, weil ein Bedarf Imagine, Upscale, Varianten und Wiederholungen umfassen kann. Vor Vertragsabschluss klären:

Ist die Abrechnungseinheit eine Aufgabe, ein erfolgreiches Bild oder ein umgerechnetes Abo-Kontingent?
Werden Upscale und Varianten separat berechnet?
Werden Fehler, Timeouts, Abbruch und Moderationsablehnung jeweils berechnet?
Werden doppelte Einreichungen und Wiederholungen doppelt berechnet, gibt es eine Idempotenz-Deduplizierung?
Gibt es Mindestumsatz, Vorauszahlungsschwelle, Erstattungsregeln und Rechnungsart?
Enthält die Verbrauchsaufstellung Aufgaben-ID, Aktionstyp, Status und abgebuchten Betrag?

Nicht nur auf den Rabatt der Werbeseite schauen. Zwanzig bis fünfzig echte Aufgaben eine Woche laufen lassen und erfolgreiche Bilder, Aufgabenzahl und Rechnung abgleichen. Bei Abweichungen eine Aufstellung pro Aufgaben-ID verlangen, nicht nur eine Summe. Kosten anderer Modelle richten sich nach den Modellpreisen; Preise passen sich dem Upstream an.

5. Key-, Konto- und Upstream-Risiken

Ein Relay bedeutet, dass Prompts, Referenzbilder und Ergebnisse über einen Dritten laufen. Mindestens klären:

Werden Prompts und Bilder gespeichert, wie lange, und für Training oder Serviceverbesserung genutzt?
Lassen sich Kontingent, IP und Ablaufzeit des Keys begrenzen, und wie wird er bei Offenlegung gesperrt?
Ist der Upstream ein einzelner Kontopool oder mehrere Kanäle, und wie wird bei Kontosperre gewechselt?
Erlauben die Bedingungen automatisierten Zugriff und Weiterverkauf, und wie ist die Haftungsgrenze?
Wer verantwortet bei Inhaltsmoderationsstreitigkeiten Einspruch und Erstattung?

Produktions-Keys gehören nicht ins Frontend, in öffentliche Repositories oder Logs. Für hochsensible Materialien bevorzugt man Anbieter ohne Persistenz und mit Datenvertrag; ist das unklar, vor dem Upload maskieren.

6. Anbieterbedingungen und Haftungsgrenzen

Ein Relay verkauft entweder „technische Dienstleistung“ oder „Modellkontingent“; die Haftung unterscheidet sich. Ein technischer Dienstleister sollte für Verfügbarkeit, Aufgabenverlust und Reaktionszeiten einstehen; ein Kontingent-Wiederverkäufer kann oft nur „Weiterleitung nach bestem Bemühen“ zusagen und ist bei Upstream-Änderungen kaum haftbar.

Im Vertrag sollten stehen: Servicelevel und Störungsmeldung, Kompensation für fehlgeschlagene Aufgaben, Vorabinformation bei Upstream-Regeländerungen, Datenverarbeitungs- und Löschpflichten sowie Datenexport und Guthabenbehandlung nach Vertragsende. Keine langfristige Zusammenarbeit akzeptieren, die nur aus Chatverläufen ohne Vertragspartei besteht.

7. Schritte von Direktverbindung oder Eigenbau zum Relay

Bestehende Aufrufe erfassen: Modelle, Parameter, Parallelität, durchschnittliche Generierungszeit und Fehlertypen.
Pfade, Authentifizierung und Feldunterschiede des Relays klären und eine Zuordnungstabelle anlegen.
In der Testumgebung die vier Wege Senden, Abfragen, Abbrechen und Download durchlaufen.
Mit derselben Prompt-Charge einen Shadow-Betrieb fahren: alte Kette und Relay parallel, nur vergleichen, nicht umschalten.
Erfolgsquote, Wartezeit, P95-Dauer, Downloadquote und Kosten pro nutzbarem Bild vergleichen.
Mit fünf bis zwanzig Prozent des Verkehrs grau umschalten und einen Rollback-Schalter behalten.
Drei bis sieben Tage beobachten und prüfen, ob Rechnung, Aufgabendetails und Geschäftsnummern zusammenpassen.
Nach Vollumschaltung eine Zeit lang beide Kanäle als Rückfall behalten und die Architektur erst danach vereinfachen.

Während der Migration weder das alte Konto noch den alten Key löschen und beide Aufgabensätze nicht unter derselben Geschäftsnummer speichern, sonst ist der Abgleich nicht mehr möglich.

8. Wie man ein Relay prüft

# Minimale Aufgabe senden, task_id und Sendezeit notieren; Pfad und Felder nach Anbieterdokumentation
curl -sS -X POST "$RELAY_BASE_URL/v1/images/generations" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"eine Katze am Fenster, die gähnt, natürliches Licht","async":true}'

# Status abfragen und den vollständigen Verlauf dokumentieren
curl -sS "$RELAY_BASE_URL/v1/tasks/$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

Beim Test gezielt Störungen erzeugen: sofort nach dem Senden abbrechen, falsche Parameter senden, parallel senden, Download unterbrechen. Beobachten, ob Status, Fehlermeldungen und Rechnung konsistent sind. Nach 24 Stunden die Ergebnisadresse erneut aufrufen, nach sieben Tagen den Aufgabendatensatz prüfen. Erst wenn diese drei Prüfungen bestehen, lohnt sich eine graue Umschaltung.

9. Monitoring und Rückweg nach der Migration

Aufgabenzahl nach Status zählen; besonders Anteile von Fehlern, Moderationsablehnung, Timeout und Abbruch.
Wartezeit und Generierungszeit getrennt erfassen, um den Engpass im Kontopool oder Upstream zu lokalisieren.
Download-Erfolgsquote überwachen; fehlgeschlagene Aufgaben in eine Kompensationswarteschlange geben.
401, 404, 429 und 5xx zählen und zwischen Key, Parameter, Ratenlimit und Upstream-Fehler unterscheiden.
Kosten „pro erfolgreich generierter Aufgabe“ rechnen, nicht nur den Preis pro Aufruf ansehen.
Rückkehr-Schwellen setzen, etwa bei deutlich unter dem Basiswert liegender Erfolgsquote über zwei Stunden zurückwechseln.

Häufige Fragen

Worin unterscheidet sich ein Relay vom direkten Midjourney-Abo?

Das direkte Abo ist das offizielle Produkt für manuelle Bedienung; ein Relay ist eine API-förmige Kapselung für Automatisierung. Parameter, Parallelität und Aufgabentransparenz können abweichen; das Relay trägt zusätzlich Kontopool- und Vertragsrisiken.

Speichert das Relay meine Prompts und Bilder?

Das ist je nach Dienst unterschiedlich. Klären, ob gespeichert wird, wie lange, wo, wer zugreifen kann, ob für Training genutzt wird und wie gelöscht wird. Bei Kundenmaterial Anbieter mit klaren Bedingungen bevorzugen.

Was tun, wenn eine Aufgabe im Relay verloren geht?

Zuerst über die Geschäftsnummer den lokalen Datensatz prüfen, dann Relay-Logs und Upstream-Aufgabe. Ist keine Wiederherstellung möglich, bleibt nur erneutes Senden; deshalb vor der Migration klären, ob das Relay Aufgaben-Zuordnungen persistiert.

Warum stimmen Rechnung und Bildzahl nicht überein?

Häufige Ursachen sind doppelte Einreichungen, Wiederholungen nach Fehlern, separat berechnete Upscales und Varianten, andere Moderationsregeln, Mindestumsatz oder abgelaufenes Guthaben. Eine Aufstellung pro Aufgaben-ID anfordern und Punkt für Punkt abgleichen.

Muss für die Migration Code geändert werden?

Ist das Relay mit der bestehenden Schnittstelle kompatibel, meist nur Base URL, Key und wenige Felder. Weichen Status-Mapping oder Callback-Format ab, müssen Polling und Datenbanklogik angepasst werden. Ein Shadow-Betrieb zeigt die meisten Unterschiede vorab.

Nächster Schritt

Legen Sie zunächst im ZSQH AI Gateway einen Test-Key an und prüfen Sie mit einer minimalen Aufgabe die vier Ketten Senden, Polling, Download und Abgleich, bevor Sie grau migrieren. Verfügbare Modelle und Kosten entnehmen Sie den Modellpreisen; Preise werden angepasst.