Fehler, Idempotenz und sichere Wiederholungen

Eine logische Operation stabil halten

Kostenpflichtige Erstellungsendpunkte erfordern Idempotency-Key mit 8–200 Zeichen. Erzeuge ihn einmal, speichere ihn mit der exakten Anfrage und verwende beides nach Timeout oder Verbindungsfehler erneut.

Derselbe Schlüssel und normalisierte Inhalt liefern die ursprüngliche Operation. Geänderter Inhalt mit demselben Schlüssel ist ein Konflikt. Eine noch angenommene Anfrage kann einen wiederholbaren In-Progress-Konflikt liefern. Schlüssel bleiben mindestens 24 Stunden erhalten; rechne nicht mit unbegrenzter Deduplizierung.

Deduplizierung gilt für Konto, Operation und API-Schlüsselidentität, bei MCP OAuth-Client. Ein anderer API-Schlüssel kann trotz identischer Idempotenzzeichenfolge einen neuen Auftrag erstellen. Stelle bei unklarer Erstellung erst eine bekannte Auftrags-ID wieder her, bevor du Zugangsdaten wechselst.

Ist das Ergebnis unklar, versuche zuerst den ursprünglichen Auftrag wiederzufinden. Erzeuge niemals stillschweigend einen neuen Schlüssel. Eine bewusst neue Generierung oder geänderte Anfrage benötigt Freigabe und neuen logischen Schlüssel.

Die Fehlerhülle lesen

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests",
    "param": null,
    "retryable": true,
    "request_id": "example-request-id",
    "details": {}
  }
}

Das Beispiel garantiert keinen identischen Meldungstext. Verzweige nach HTTP-Status und error.code, prüfe retryable und behalte request_id für Support. Protokolliere keine rohen Header, Bildinhalte, Prompts oder signierten URLs.

Eine Reaktion wählen

Eigentumsfehler können absichtlich wie Nicht-gefunden-Antworten aussehen. Teste keine fremden IDs durch.

Jede Wiederholungsschleife begrenzen

Beachte Retry-After als Sekunden oder HTTP-Datum, sonst exponentielle Wartezeit mit Zufallsanteil. Begrenze Versuche und Gesamtdauer. Eine lokale Frist stoppt das Warten, nicht bereits angenommene entfernte Aufträge.

Wiederhole Leseoperationen nach vorübergehenden Transportfehlern. Wiederhole unklare kostenpflichtige Erstellung nur mit gespeichertem Idempotenzschlüssel und unverändertem Inhalt. Wiederhole Uploads ohne Schlüssel oder andere nicht idempotente Operationen niemals blind.

Speichere bei Fristablauf die bekannte Auftrags-ID und setze später fort. Prüfe nach endgültigem Fehler Teilergebnisse, bevor du neuen Export oder neue Generierung wählst.

Kontolimits und Diagnose

PROVIDER_CONTENT_REJECTED kennzeichnet derzeit bestätigte Seedance-Inhaltsablehnung, keinen vorübergehenden unverändert zu wiederholenden Fehler. Lies credits.status, credits.refunded und credits.released. credits.charged ist bereits die Nettobelastung; ziehe Rückgaben nicht erneut ab. Bestätigte Ablehnung vor Ausgabe/Export gibt den ursprünglichen Ein-Aufruf-Betrag zurück. Lokaler Timeout oder Exportfehler sind andere Fälle. Eine Rückgabe genehmigt keinen weiteren kostenpflichtigen Auftrag.

Lies aktuelle Limits über GET /account; Rate-Limit-Header können den aktuellen Zähler beschreiben. Mehr Schlüssel erhöhen keine Kontokapazität. Verteile Statusabfragen statt gleichzeitiger Anfragestöße aller Clients.

Support benötigt öffentliche Anfrage-ID, bekannte Auftrags-ID, Zeitpunkt, Fehlercode und kurze Beschreibung. Schwärze Geheimnisse und private Eingaben. Siehe Statusabfragen und Downloads für unvollständige Ergebnisse und das Python-Beispiel für begrenzte Wiederholungen.