Ihre Charakter-App für Erwachsene verspricht ein neues Bild. Der Kunde tippt auf Generieren, die Ladeanzeige läuft eine Weile, dann meldet die Seite einen Verbindungstimeout. Er tippt erneut. Eine Minute später erscheinen zwei Bilder und das Guthaben ist zweimal gesunken.
Das zweite Bild mag schön sein. Trotzdem ist es ein teurer Weg zu erkennen, dass ein Verbindungstimeout keine gescheiterte Generierung ist.
Bei einer NSFW-Bild-API heißen drei unterschiedliche Aktionen oft „Retry“: eine bestehende Aufgabe prüfen, ihre ursprüngliche Einreichung wiederholen und einen weiteren kreativen Versuch bezahlen. Halten Sie sie getrennt. Haben Sie eine Aufgaben-ID, prüfen Sie diese Aufgabe. Ist die Erstellungsantwort verschwunden, wiederholen Sie die unveränderte Anfrage mit ihrem ursprünglichen Idempotenzschlüssel. Wurde die Aufgabe abgeschlossen, aber das Bild verfehlt das Briefing, ist eine weitere Generierung ein neuer Kauf.
Der letzte Unterschied ist gerade bei Charakterbildern für Erwachsene wichtig. Ein Modell kann erfolgreich abschließen und dabei die gewünschte Szene abschwächen, ein Outfit ändern oder ein anderes Gesicht erzeugen. Aufgabenerfolg bedeutet, dass ein Ergebnis geliefert wurde; er verspricht nicht, dass Sie es verwenden möchten.
Was ist passiert, und welchen Button sollten Sie anbieten?
| Was der Kunde sieht | Was tatsächlich bekannt ist | Nächste Aktion |
|---|---|---|
| Timeout vor Rückgabe einer ID | Annahme ist ungewiss | Dieselbe Erstellungsanfrage mit demselben Schlüssel wiederholen |
Eine ID liegt vor, die Aufgabe ist queued oder running | Eine Generierung existiert bereits | Status prüfen; keine weitere Aufgabe erstellen |
Die Aufgabe ist failed oder expired | Der Versuch hat einen Endzustand erreicht | Grund und endgültige Belastung vor einem neuen Versuch lesen |
| Das Modell hat die NSFW-Anfrage abgelehnt | Diese konkrete Anfrage wurde zurückgewiesen | Inhaltsverhalten und Abrechnungshinweis der genauen Modellaufgabe prüfen |
| Bild vorhanden, aber Figur oder Szene falsch | Generierung erfolgreich; kreative Absicht verfehlt | Entscheiden, ob Bearbeitung oder neue Variante eine weitere Belastung rechtfertigt |
| Bild lässt sich nicht herunterladen | Lieferung gestört oder Link abgelaufen | Vorhandenes Asset wiederherstellen, solange es verfügbar ist |
Warten, Einreichung wiederherstellen und eine neue Variante sind unterschiedliche Aktionen.
Eine hilfreiche Oberfläche für Creator für Erwachsene könnte Vorhandenes Bild prüfen, Einreichung wiederherstellen, Weitere Variante generieren und Download erneut versuchen anzeigen. Ein einziges Retry-Label verbirgt den Unterschied zwischen kostenloser Statusprüfung und Freigabe neuer Generierungsausgaben.
Behalten Sie mit Aufgaben-ID die ursprüngliche Aufgabe
SpicyAPIs asynchroner Bildworkflow nimmt eine Anfrage an, gibt eine Aufgaben-ID zurück und stellt das Bild später bereit. Eine angenommene Erstellungsantwort ist noch nicht das fertige Bild. Die Aufgabe durchläuft Zustände wie queued, running und succeeded; auch failed, canceled und expired sind Endzustände.
Speichern Sie die Aufgaben-ID unmittelbar nach Empfang auf dem Server, bevor Sie den Browser aktualisieren. Aktualisiert ein Kunde die Seite, meldet sich erneut an oder öffnet das Projekt auf einem anderen Gerät, sollte Ihre Anwendung die gespeicherte Aufgabe abrufen statt den Prompt erneut einzureichen.
Ein Creator fordert etwa ein neues Abendporträt seiner fiktiven erwachsenen Figur an. Ihr Server erhält eine Aufgaben-ID, aber der Browser verliert die Verbindung vor Anzeige der Wartekarte. Beim Zurückkehren sollte die Karte ihre Verbindung zu dieser Aufgabe fortsetzen. Eine Seitenaktualisierung ist keine Anfrage nach einem zweiten Porträt.
Nutzen Sie GET /api/v1/jobs/recordInfo mit der Aufgaben-ID, um den aktuellen Zustand abzurufen. Die Aufgabendokumentation beschreibt Anfrage und Antwort. Ein Webhook kann Abschlussmeldungen liefern, aber ein verzögerter Webhook macht die vorhandene Aufgabe nicht zum Fehlschlag. Polling bleibt ein Wiederherstellungsweg.
Machen Sie eine lokale Wartegrenze nicht zur Abrechnungsentscheidung. Der Browser wartet vielleicht nach 30 Sekunden nicht mehr, die ausgehende HTTP-Anfrage Ihres Servers nach 60 Sekunden, während die entfernte Aufgabe weiterläuft. Der zurückgegebene Aufgabendatensatz enthält eine Ausführungsfrist, deadlineAt; sie beschreibt die entfernte Ausführung, nicht die Dauer der Seitenverbindung. Der Ablauf des Downloadlinks ist wiederum eine andere Frist.
Zeigen Sie auf dem Wartebildschirm beispielsweise: „Ihr Bild wird noch verarbeitet. Sie können diese Seite verlassen und zu derselben Aufgabe zurückkehren.“ Versprechen Sie keine genaue Fertigstellungszeit ohne Messwerte für das konkrete Modell und die Arbeitslast. Die gemessene Latenz eines Wettbewerbers für gewöhnliche Produktbilder ist keine Zeitgarantie für Ihre NSFW-Prompts.
Bei verlorener Erstellungsantwort dieselbe Einreichung wiederholen
Schwierig ist eine Verbindung, die nach dem Senden der Anfrage durch Ihren Server, aber vor der Bestätigung abbricht. Dieser Verbindungsfehler sagt nicht, ob die Plattform den Auftrag angenommen hat.
SpicyAPI bietet eine echte serverseitige Absicherung: den optionalen Header Idempotency-Key. Bei demselben Konto und API-Key liefert derselbe Schlüssel mit identischem normalisiertem Modell, Input und Callback-URL innerhalb von 24 Stunden die ursprüngliche Aufgabe zurück, statt erneut Mittel zu reservieren. Eine geänderte Anfrage kollidiert mit dem Schlüssel. Auch ein anderer API-Key desselben Kontos kann seine Zuordnung nicht wiederholen; er erhält einen Konflikt, ohne dass die ursprüngliche Aufgaben-ID offengelegt wird.
Erstellen Sie einen stabilen Schlüssel für das vom Kunden gewünschte Bild, nicht für jeden HTTP-Versuch. Ein von der Anwendung erzeugter Wert wie project-8-image-12-v1 verdeutlicht das Prinzip. Halten Sie persönliche Details und rohen Prompttext heraus. Erzeugen und speichern Sie ihn vor der ersten Erstellungsanfrage. Ein neuer Netzwerkversuch nutzt ihn erneut; ein tatsächlich neues Bild erhält eine neue Version oder Vorgangs-ID.
Eine minimale Wiederherstellungsfolge ist:
- Speichern Sie beabsichtigten Bildvorgang, ursprünglichen Request-Body und Schlüssel in Ihrer Anwendung.
- Senden Sie die Anfrage mit
Idempotency-Key. - Geht die Bestätigung verloren, markieren Sie den lokalen Vorgang als auf Bestätigung wartend.
- Wiederholen Sie unveränderten Body und Schlüssel mit demselben API-Zugang.
- Speichern Sie die zurückgegebene Aufgaben-ID und wechseln zur Statusprüfung.
Halten Sie während der Wiederherstellung die exakt gesendete Anfrage stabil. Lassen Sie die Oberfläche sie nicht aus Einstellungen neu aufbauen, die der Kunde inzwischen geändert haben könnte. Wechselt der Creator vom Nahporträt zur weiteren Komposition, erhöht die Auflösung oder ändert Prompt beziehungsweise Callback-URL, ist das nicht mehr die ursprüngliche Einreichung.
Die Absicherung ist begrenzt: 24 Stunden sind kein unbegrenzter Speicher für die Duplikatverhinderung Ihrer Anwendung. Nach diesem Fenster dürfen Sie nicht annehmen, dass der alte Schlüssel einen alten Auftrag wiederherstellt. Ihre eigene dauerhafte Zuordnung von Vorgang zu Aufgabe muss spätere Rückkehr abdecken. Bleibt die Annahme ungewiss und können Sie den ursprünglichen Auftrag nicht identifizieren, gleichen Sie die Aufgabenprotokolle des Kontos ab oder fragen den Support, bevor Sie automatisch Ersatz erstellen.
Ein deaktivierter Generieren-Button hilft, reicht aber nicht
Ein während des Ladens deaktivierter Button verhindert einen häufigen Doppeltipp. Er verhindert keine Duplikate aus zwei Browsertabs, einem erneut verbundenen mobilen Client, einem Hintergrundworker oder einem Serverneustart.
Ihre Anwendung sollte all diese Ereignisse einem logischen Bildvorgang zuordnen. Eine Eindeutigkeitsregel in Ihrer Datenbank verhindert, dass zwei Worker unabhängig denselben Vorgang übernehmen. Der Plattform-Idempotenzschlüssel schützt anschließend die entfernte Erstellungsgrenze. Das sind unterschiedliche Schutzmaßnahmen; hat Ihre App mehr als einen Weg zum Einreichen, braucht sie beide.
Nehmen wir ein Companion-Produkt, das nach einem Gespräch optional ein neues Charakterporträt generiert. Der Nutzer drückt zusätzlich den manuellen Porträtbutton, bevor die automatische Anfrage bestätigt ist. Sollen beide Aktionen dieselbe Porträtanfrage erfüllen, verknüpfen Sie sie mit einem Vorgang. Fordert der manuelle Button ausdrücklich eine zweite Variante, zeigen Sie die weitere bezahlte Generierung. Fassen Sie weder zwei bewusste Käufe still zusammen noch berechnen Sie unbemerkt zweimal ein Versprechen.
Der Schlüssel bestimmt diese Produktbedeutung nicht. Ihre Anwendung entscheidet, was dieselbe Anfrage ist. Auch eine lokal deduplizierte Datenbankzeile hilft nicht, wenn der ausgehende Client jede Wiederherstellung mit frischem entferntem Schlüssel sendet. Der Wert muss den gesamten Weg überdauern.
Ablehnung, technischer Fehler und unerwünschtes Bild haben unterschiedliche Rechnungen
Eine Anfrage für Erwachsene kann unterschiedlich enden. Vermeiden Sie das pauschale Versprechen, gescheiterte NSFW-Generierungen kosteten immer nichts, ebenso wie die gegenteilige Behauptung, jeder Fehler werde berechnet.
Aufgabenstatus und kreative Zufriedenheit unterscheiden sich. Prüfen Sie den abgerechneten Datensatz und modellspezifische Abrechnungsausnahmen.
SpicyAPI reserviert bei Annahme einer Aufgabe einen geschätzten Betrag. Solange settled false ist, bezeichnet cost die reservierte Schätzung. Nach der Abrechnung steht es für die endgültige Belastung. Eine erfolgreiche Aufgabe wird bis zum reservierten Betrag berechnet; ungenutzte Mittel werden freigegeben.
Eine gescheiterte oder abgelaufene Aufgabe gibt ihre Reservierung normalerweise frei. Die Rückerstattungsrichtlinie beschreibt Ausnahmen, darunter Modelle mit auf der Seite genannten Kosten für abgelehnte oder gescheiterte Anfragen sowie vor einem Abbruch bereits gelieferte Nutzung. Bei einer vom Modell abgelehnten Bildaufgabe prüfen Sie dessen Abrechnungshinweis und den endgültig abgerechneten Datensatz. Erklären Sie die Kontobewegung nicht allein aus dem HTTP-Fehler.
Ein erfolgreiches, aber abgeschwächtes Bild ist etwas anderes. Sie haben etwa eine selbstbewusste fiktive erwachsene Figur in einer bestimmten Editorial-Szene für Erwachsene verlangt und ein gewöhnliches Porträt erhalten. Hat die Aufgabe erfolgreich ein Ergebnis geliefert, macht Unzufriedenheit mit der Szene daraus keinen erstattungsfähigen technischen Fehler. Das gilt ebenso für falsche Frisur, unerwünschtes Accessoire oder unpassenden Ausdruck.
Darum braucht eine nützliche Retry-Regel ein kreatives Ausgabenlimit, nicht bloß eine Anzahl von Netzwerkwiederholungen. Ein Worker, der jedes Ihrer App missfallende Bild wiederholt, kauft möglicherweise lange nach Behebung technischer Fehler weiter erfolgreiche Ausgaben.
Lesen Sie die genaue Modellseite der verwendeten Aufgabe. Eine permissive Text-to-Image-Route beweist kein identisches Verhalten der Bearbeitungsroute, und ein Familienname sagt nicht jede NSFW-Anfrage voraus. Verwenden Sie ausschließlich erwachsene Figuren und Material, das Sie berechtigt einreichen dürfen. Wiederholungen machen unzulässige Anfragen nicht zulässig.
Ein neuer Versuch nach Endzustandsfehler erzeugt neue Arbeit
Die API bietet auch POST /api/v1/jobs/retry: Es nimmt eine Quellaufgaben-ID und erstellt aus einem berechtigten endgültigen Fehlschlag eine neue Aufgabe. Die alte Aufgabe läuft dadurch nicht wieder an. Aktuelle Modelleingaben, Berechtigungen, Verfügbarkeit, Guthaben und Preise werden neu bewertet. Die Quelle benötigt aufbewahrte Eingaben und abgeschlossene Abrechnungsabstimmung; aktive oder erfolgreiche Aufgaben sind nicht für diese Retry-Aktion berechtigt.
Nutzen Sie denselben API-Key wie bei Erstellung der Quellaufgabe. Ein Idempotenzschlüssel für die Retry-Aktion schützt genau diesen neuen Versuch und ist auf die Quellaufgabe begrenzt. Wiederholen der Retry-Aktion kann deren neu erstellte Aufgabe wiederherstellen; das unterscheidet sich vom Wiederholen der ersten Erstellungsanfrage zur Wiederherstellung des Originals.
Zeigen Sie dies in einer Creator-App als frischen Generierungsversuch mit Preis. Muss der Prompt geändert werden, erstellen Sie eine neue Anfrage mit überarbeiteter Eingabe, statt die Änderung vom Quellaufgaben-Retry zu erwarten. Eine wegen abgelaufener Referenz gescheiterte Anfrage braucht ebenfalls eine brauchbare Referenz für den nächsten Erfolg. Freigabe der ursprünglichen Belastung und Reservierung des neuen Versuchs sind getrennte Einträge.
Was wiederholte Versuche tatsächlich kosten
Hier sind aktuelle Ausgangskonfigurationen dreier Bildendpunkte. Die Preise beschreiben Generierung, keine Garantie, dass jedes Bild ein NSFW-Briefing erfüllt.
Hypothetisches Planungsbeispiel: Versehentliche doppelte Aufgaben ergänzen $7.20 bewusste kreative Versuche um $2.40.
| Endpunkt und explizite Konfiguration | Preis je Bild | Drei berechnete Versuche | Zehn berechnete Versuche |
|---|---|---|---|
| Z-Image Turbo Text-to-Image, Prompt-Erweiterung aus | $0.010 | $0.030 | $0.100 |
| Qwen Image 2.1 Text-to-Image, 1K | $0.024 | $0.072 | $0.240 |
| Seedream 5.0 Pro Text-to-Image, 1K ausgewählt | $0.036 | $0.108 | $0.360 |
Die Details sind wichtig. Z-Image Turbo mit aktivierter Prompt-Erweiterung kostet $0.016 statt $0.010 pro Bild. Seedream 5.0 Pro verwendet standardmäßig 2K zu $0.072 statt seines 1K-Preises von $0.036. Die explizite Stufenwahl bringt die Rechnung mit dem Auftrag in Einklang.
Angenommen, Sie planen 100 fertige Qwen-Image-2.1-Porträts bei 1K. Benötigt jedes durchschnittlich drei berechnete kreative Versuche, kostet die Generierung $7.20: 100 × 3 × $0.024. Dupliziert ein Bestätigungsfehler zusätzlich für jedes Endbild eine Einreichung, kommen 100 × $0.024 = $2.40 hinzu, insgesamt $9.60. Das sind Planungsbeispiele, keine gemessene Erfolgsquote.
Ein kreativer Prozess mit drei Versuchen wird durch anderen HTTP-Timeout nicht zum Ein-Versuch-Prozess. Den versehentlichen vierten Versuch können Sie entfernen. Führen Sie bewusste Varianten und versehentliche Duplikate in getrennten Summen, damit das bezahlte Problem sichtbar wird.
Bestimmen Sie in einem kleinen Creator-Workflow vor der Generierung die Grenze: vielleicht ein erstes Bild plus zwei überarbeitete Versuche für diesen konkreten Platz. Das ist ein Vorschlag zum App-Budget, keine Plattformgrenze. Verfehlen alle drei dieselbe Anforderung, hören Sie auf, nahezu identische Anfragen zu kaufen, und ändern den Ansatz.
Ein fertiges NSFW-Bild verfehlt das Briefing: Einen relevanten Punkt ändern
Ist das Gesicht richtig, aber Raum oder Outfit falsch, kann gezielte Bearbeitung der bessere nächste Kauf als ein völlig neuer Text-to-Image-Versuch sein. Bewahren Sie das nützliche Ergebnis, beschreiben die Änderung und wählen ein Modell mit passender Bearbeitungsaufgabe. Bearbeitung kostet weiterhin Geld; sie ist keine im ursprünglichen Kauf enthaltene Gratiskorrektur.
Erzeugt dieselbe Anfrage fortlaufend eine abgeschwächte Szene, klären Sie zuerst, ob eine Inhaltsablehnung, konservative Interpretation einer erlaubten Anfrage oder ein überladener Prompt vorliegt. Wiederholtes Senden desselben Prompts sagt nicht, welcher Fall eingetreten ist. Prüfen Sie geliefertes Bild und gegebenenfalls stabilen Fehlercode, statt das NSFW-Schlüsselwort als universellen Schalter zu behandeln.
Ein nichtgrafisches Planungsbeispiel könnte eine fiktive erwachsene Figur, dunkle Satinjacke, Sitzpose, warmes Seitenlicht und einen aufgeräumten Raum verlangen. Enthält jedes Ergebnis einen überladenen Raum, entfernen Sie sekundäre Setdetails und behalten Charakter- und Lichtanweisungen. Erscheint das falsche Gesicht, wechseln Sie zum passenden referenzbasierten Workflow, statt einem reinen Textprompt weitere Adjektive hinzuzufügen.
Ist eine echte neue Variante nötig, verwenden Sie neuen Vorgang und Schlüssel. Die erste angenommene Anfrage mit ihrem ursprünglichen Schlüssel zu wiederholen stellt die erste Aufgabe wieder her; es fordert kein besseres zweites Bild an. Ändern Sie einen Seed für eine neue Variante, erfassen Sie dies als neuen kreativen Versuch. Ein Seed hilft bei der Anfrageidentifizierung, garantiert aber keine identische Figur über verschiedene Modelle.
Vergleichen Sie nach den ersten Versuchen Kosten je fertigem brauchbarem Bild statt bloß beworbener Einstiegspreise. Eine viermal genutzte $0.010-Generierung kostet $0.040, eine einmal genutzte $0.024-Generierung $0.024. Diese Rechnung belegt keine höhere Zuverlässigkeit des zweiten Modells, sondern zeigt, was Sie für Ihr Charakterbriefing messen sollten.
Wenn ein vorhandenes Bild nicht heruntergeladen werden kann
Generieren Sie ein erfolgreiches Bild nicht neu, nur weil sein Download einen Fehler liefert. Die Datei kann weiterhin existieren, während der temporäre Zugangslink nicht mehr funktioniert oder Ihre Anwendung beim Kopieren scheitert.
Behalten Sie abgeschlossene Aufgabe und Ausgabeasset-Identität. Stellen Sie einen aktuellen autorisierten Downloadweg wieder her, solange die Ausgabe aufbewahrt wird, und übertragen dieses Asset erneut. Hängen Sie keinen API-Key an eine separate signierte Medien-URL. Prüfen Sie vor „Gespeichert“ in der Kundenbibliothek, dass das Ziel die tatsächlichen Bytes enthält.
Der Leitfaden zur Medienauslieferung behandelt das Kopieren in eigenen Speicher. Für einen Creator für Erwachsene ist das zugleich eine Datenschutzgrenze: Ein generiertes Bild oder eine Referenz wird durch erfolgreiches Kopieren nicht automatisch zum öffentlichen Galerieasset. Die Wiederherstellung muss den vorgesehenen privaten Zugriff erhalten.
Wurde die ursprüngliche Ausgabe nach der wirksamen Aufbewahrungsregel bereits gelöscht, stellt eine Aufgaben-ID die fehlenden Bytes nicht wieder her. Ersatz wäre eine neue Generierung und könnte anders aussehen. Erklären Sie dem Kunden diesen Unterschied, statt ein altes Porträt still durch ein neu berechnetes zu ersetzen.
Lassen Sie die nächste Kundenaktion zur Belastung passen
Zeigen Sie den Status einer vorhandenen Aufgabe zusammen mit ihrer endgültigen Belastung. Bleibt der Auftrag ungeklärt, behalten Sie seinen Platz im Projekt, statt einen frischen bezahlten Versuch als einzigen Ausweg anzubieten. Ist er gescheitert, zeigen Sie Grund und Freigabe des reservierten Betrags. Bei Erfolg trennen Sie „Erneut herunterladen“ von „Weitere Variante generieren“.
Für den Support helfen Aufgaben-ID, gegebenenfalls Anfrage-ID, Zeitstempel, Betrag und eine kurze Problembeschreibung. Zwei unterschiedliche erstellte Aufgaben-IDs sind etwas anderes als eine doppelt belastete Aufgabe. Die Rückerstattungsrichtlinie fordert ausdrücklich Meldungen zu doppelten Belastungen, Beträgen über der Reservierung, nicht gelieferten erfolgreichen Ausgaben oder innerhalb von 24 Stunden nicht zurückgegebenen Reservierungen gescheiterter Aufgaben. Schreiben Sie API-Keys, signierte Medienlinks oder sensible kreative Prompts nicht in gewöhnliche Logs oder Supportscreenshots.
Ein Creator sollte den Verlauf als „ein Porträt angefordert, eine Einreichung wiederhergestellt, ein Ergebnis geliefert“ verstehen können, statt als Liste unsichtbarer HTTP-Versuche. Das ist das Ziel: Netzwerkwiederherstellung bewahrt den ursprünglichen Kauf; ein weiterer kreativer Versuch ist eine bewusste Entscheidung mit sichtbarem Preis.
