Eine Bildintegration zu SeedRouter verschieben

Eine Migration der Bild-API zu SeedRouter verlangt, den Vertrag für Anfrage und Antwort zu prüfen, nicht nur API-Schlüssel und Basis-URL auszutauschen. GPT Image 2 nutzt vertraute Felder zur Bildgenerierung, doch das Absenden liefert eine Aufgaben-ID zurück. Deine Anwendung muss diese ID speichern, bis zum Abschluss abfragen und die fertigen Bild-URLs lesen.

Die kleinste sinnvolle Migration ist eine Text-zu-Bild-Anfrage aus serverseitigem Code. Bring diese zum Laufen, bevor du Referenzbearbeitungen, Masken oder größere Mengen umstellst. Halte die bestehende Integration verfügbar, bis der neue Weg dieselben Abnahmeprüfungen besteht.

Welche Annahmen müssen sich ändern?

Such den Code, der eine Bildanfrage in eine nutzbare Datei verwandelt. Vielleicht erwartet er derzeit ein Bild in der ersten Antwort, decodiert ein base64-Feld oder nutzt einen Multipart-Upload. Diese Annahmen müssen einzeln gegen die SeedRouter-Referenz zu GPT Image 2 geprüft werden.

Deshalb ist ein synchroner Aufruf eines Images-SDK kein direkter Ersatz, selbst wenn er eine konfigurierbare Basis-URL annimmt. Behalte die Modelleinstellungen, die du weiterhin brauchst, pass aber den Anwendungscode an, der auf das Ergebnis wartet und es verarbeitet.

Ordne die Anfragefelder zu, bevor du Code verschiebst

Beginne mit model, prompt, size, quality und n. Verwende gpt-image-2 als Modell-ID. Sende explizite Maße wie 1024x1024 oder nutze auto; übernimm kein separates resolution-Feld und keinen Seitenverhältnis-String als Größe.

Das OpenAPI-Dokument von SeedRouter ist eine nützliche Begleitung bei der Prüfung. Vergleiche die Felder, die deine Anwendung tatsächlich sendet, einschließlich der von einem SDK ergänzten Werte, statt nur die an der Aufrufstelle sichtbaren Argumente zu prüfen. Unbekannte Felder werden abgelehnt.

Für dieses Modell sind style, response_format und ein konfigurierbares input_fidelity keine akzeptierten Anfragefelder. Entferne diese Annahmen, statt sie in einem generischen Options-Objekt zu verstecken. Die Anfrage unterstützt auch stream und partial_images nicht; den Fortschritt meldet diese Integration über den Aufgabenstatus.

Ausgabeeinstellungen hängen voneinander ab. Forderst du Transparenz an, wähle PNG. Sende output_compression nur bei JPEG, nicht bei PNG. Der Kompressionswert null ist gültig; vermeide daher eine Wahrheitsprüfung, die ihn durch einen Standardwert ersetzt. Das sind kleine Details, die eine erfolgreiche Basisanfrage nicht berührt.

Ersetze die Annahme einer synchronen Antwort

Das folgende Node.js-Beispiel sendet eine Anfrage und gibt deren Aufgaben-ID aus. Setz SEEDROUTER_API_KEY auf dem Server; leg den Schlüssel niemals in Browser-Code oder eine öffentliche Umgebungsvariable.

const response = await fetch('https://api.seedrouter.ai/v1/images/generations', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.SEEDROUTER_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    model: 'gpt-image-2',
    prompt: 'A cobalt-blue ceramic mug on a pale gray tabletop.',
    size: '1024x1024',
    quality: 'low',
    n: 1,
  }),
  signal: AbortSignal.timeout(60000),
});
const task = await response.json();
if (!response.ok) {
  // Preserve a task reference if one accompanies an uncertain submission.
  if (typeof task.id === 'string') console.log('Task reference:', task.id);
  throw new Error(`Submission needs review: HTTP ${response.status}`);
}
if (typeof task.id !== 'string' || !task.id) throw new Error('Missing task ID.');
console.log(task.id); // Persist this ID with your application's image record.

Für einen manuellen Rauchtest genügt es, die ID auszugeben. In einer Anwendung speicherst du sie, bevor du die Kontrolle an den Nutzer zurückgibst. So bleibt dein Bilddatensatz offen, während der Nutzer weiternavigiert, und eine spätere Prüfung kann das Ergebnis wiederherstellen.

Prüfe den Fortschritt mit GET https://api.seedrouter.ai/v1/tasks/{id} und demselben Autorisierungs-Header. Bei completed liest du output.data[].url. Bei failed behandelst du den dokumentierten Fehler und zeigst einen passenden Fehlerzustand. Ein lauffähiges Beispiel, das den Fortschritt speichert, findest du unter Batch-Absenden und Abfragen.

Häng den API-Schlüssel nicht an die Anfrage zum Bild-Download. Die Autorisierung gehört zum Aufruf der Aufgaben-API, nicht zum separaten Abruf einer zurückgegebenen Asset-URL.

Referenzen und Masken auf URL-Eingaben umstellen

Ein bestehender Ablauf mit lokalen Dateien braucht einen zusätzlichen Vorbereitungsschritt: Stell das Referenzbild unter einer erreichbaren HTTP(S)-URL bereit, die du kontrollierst. Übergib es als images: [{"image_url": "https://example.com/reference.png"}] und ersetze die Adresse durch deine eigene. Sende keinen Dateipfad, keine blob:-URL, keine base64-Data-URL und keine Files-ID.

Prüfe, ob die URL ohne die Login-Cookies deines Browsers funktioniert. Eine URL, die sich nur in deiner angemeldeten Sitzung öffnet, ist für diese Anfrage keine nutzbare Referenz. Halte das Bild erreichbar, solange die Aufgabe läuft; entzieh den Zugriff nicht unmittelbar nach dem Absenden.

Eine Maske wird als mask: {"image_url": "https://example.com/mask.png"} angegeben und erfordert Referenzbilder. Sie muss den Abmessungen des ersten Referenzbildes entsprechen. Prüfe alle Beschränkungen für Medieneingaben, bevor du einen bestehenden Bearbeitungsablauf umstellst, besonders Dateiformate und Dateigrößen.

Was sollte der Abnahmetest der Migration abdecken?

Teste das Verhalten, auf das sich deine Anwendung stützt, einschließlich Unterbrechungen. Ein erfolgreiches Bild belegt nur, dass eine Anfrage funktioniert hat. Es belegt nicht, dass dein Wartezustand ein Neuladen übersteht oder dass ein fehlgeschlagener Download doppelte Generierungen vermeidet.

• Eine reine Textanfrage senden und die zurückgegebene ID vor dem Abfragen speichern.
• Das Abfragen stoppen, mit derselben ID neu starten und prüfen, dass kein zusätzlicher POST erfolgt.
• processing, completed und failed als eigenständige Zustände behandeln.
• Ein fertiges Bild herunterladen, ohne den API-Autorisierungs-Header zu senden.
• Eine Referenzbearbeitung mit erreichbarer URL prüfen und danach die Fehlerbehandlung bei einer nicht erreichbaren.
• Optionale Felder, auch die Kompression mit Wert null, anhand des veröffentlichten Schemas validieren.
• Bestätigen, dass Kontobeträge aus dem Nutzungsverlauf gelesen werden und nicht aus einem erfundenen Kostenfeld der Aufgabenantwort.

Nutze nachgebildete Antworten für wiederholbare Fehler- und Timeout-Tests. Führ einen kleinen, bewussten Live-Test erst durch, wenn diese Prüfungen bestehen; echte Generierungen verbrauchen Guthaben. Ist das Ergebnis des Absendens unklar, untersuche es, bevor du es erneut versuchst. Eine lokale Ausnahme ist kein Beleg dafür, dass keine Aufgabe angenommen wurde.

Häufige Fragen

Kann ich meine bestehenden Prompts behalten?

Ja, als Ausgangspunkt, sofern sie die Anfragevorgaben erfüllen. Behalte einige repräsentative Prompts zum Vergleich, erwarte aber keine identischen Bilder aus wiederholten Generierungen.

Brauche ich eine neue Client-Bibliothek?

Für die Beispiele hier nicht. Standard-HTTP-Anfragen genügen. Welchen Client du auch wählst, er muss das Absenden von Aufgaben und das Abfragen beherrschen, statt sofort ein fertiges Bild zu erwarten.

Wo finde ich die endgültigen Kosten?

Im Nutzungsverlauf des Kontos. Eine abgeschlossene Aufgabe kann den Token-Verbrauch enthalten, doch ihre öffentliche Antwort hat kein Kostenfeld. Schätzungen behandelt der Preisleitfaden.

Schließ die Migration an der Anwendungsgrenze ab

Eine Bild-API-Migration ist abgeschlossen, wenn die Anwendung den gesamten Lebenszyklus des Ergebnisses beherrscht: angenommene Aufgabe, Wartezustand, fertige Ausgabe, Download und Fehlschlag. Halte die erste Änderung klein, teste die Unterbrechungsfälle und verschieb die übrigen Anfragen erst, wenn deren Ein- und Ausgabeannahmen geprüft sind.