Skip to main content
Fehler treten an zwei verschiedenen Stellen auf, mit zwei verschiedenen Vokabularen:
  • API-Anfragefehler — die HTTP-Antwort auf einen synchronen API-Aufruf (Authentifizierung, Abrechnung, fehlerhafte Anfragen, nicht vorhandene Ressourcen). Siehe API-Anfragefehler.
  • Fehlercodes für fehlgeschlagene Predictions — die Anfrage wurde angenommen und in die Warteschlange gestellt, aber die Prediction selbst endete mit status: "failed". Der Fehler wird durch das error-Objekt der Prediction beschrieben, das Sie über die Prediction-Status-Endpunkte, über Webhook-Zustellungen und über den Result-Endpunkt erhalten. Siehe Fehlercodes für fehlgeschlagene Predictions.

Fehlercodes für fehlgeschlagene Predictions

Eine fehlgeschlagene Prediction trägt ein error-Objekt:
Fehlgeschlagene Predictions werden nicht berechnet; das für die Anfrage reservierte Guthaben wird wieder freigegeben. Eine Prediction, die nicht fehlgeschlagen ist, trägt error: null. Siehe Hinweis zur Migration, wenn Sie vor dem 17. August 2026 integriert haben.

Wo der Fehler bei Ihnen ankommt

Dasselbe error-Objekt wird auf jedem Kanal veröffentlicht; Sie können es also dort lesen, wo Sie ohnehin hinschauen:

Einen Fehler über den Result-Endpunkt lesen

Wer die Ausgabe einer fehlgeschlagenen Prediction abruft, erhält eine 400 mit genau dem Fehler, der dazu geführt hat, unter dem Code auf Anfrageebene PREDICTION_FAILED:
Zwei Codes auf zwei Ebenen — und sie gehören nicht zum selben Vokabular:
  • error.code ist PREDICTION_FAILED, ein API-Anfragefehler mit der Bedeutung „die Prediction, deren Ausgabe Sie angefordert haben, hat keine erzeugt“;
  • error.details ist das error-Objekt der Prediction selbst — identisch mit dem, was /status für dieselbe Anfrage meldet, sodass die beiden Endpunkte sich über die Fehlerursache niemals widersprechen können. Verzweigen Sie über error.details.reason und error.details.retryable.
error.message wiederholt die Meldung der Prediction, sodass auch ein Client, der nur die Meldung der obersten Ebene liest, etwas Brauchbares erhält. Zwei Timestamps, zwei Bedeutungen. Der timestamp der obersten Ebene gibt an, wann diese HTTP-Antwort erzeugt wurde; error.details.timestamp gibt an, wann die Prediction fehlgeschlagen ist. Bei einer Prediction, die Sie Tage später abrufen, liegen beide Tage auseinander. Lesen Sie immer den inneren Wert, wenn Sie den Fehler meinen. Die offiziellen Client-Bibliotheken packen das für Sie aus: result() wirft einen Fehler, dessen code, reason und retryable die der Prediction selbst sind — identisch mit dem, was subscribe() für denselben Fehler wirft. Eine Prediction, die noch in der Warteschlange steht oder noch läuft, sowie eine abgebrochene Prediction geben weiterhin dieselbe generische 400 zurück wie bisher.

Entscheiden, ob ein erneuter Versuch sinnvoll ist

Lesen Sie retryable. Es beantwortet genau eine Frage — führt dieselbe Anfrage, erneut gesendet, zu einem anderen Ergebnis? — und ist unabhängig von code: derselbe code kann bei einem Fehler wiederholbar sein und bei einem anderen nicht. retryable ist optional. Fehlt es, greifen Sie auf den Standardwert je code aus der folgenden Tabelle zurück. Genau so hat sich Sunra verhalten, bevor es dieses Feld gab; der Rückgriff ist also immer sicher, nur weniger präzise.

code

reason

reason benennt die konkrete Ursache hinter code. Verwenden Sie es für Metriken, Routing und Support-Diagnose; für die Entscheidung über einen erneuten Versuch verwenden Sie retryable. Jede heute veröffentlichte Reason hat unten ihren eigenen Abschnitt, und ihr Anker ist die Reason selbst — #input_fetch_failed, #moderation_blocked und so weiter —, sodass ein Fehlerbericht direkt auf ihre Bedeutung verlinken kann.

input_validation_failed

code: invalid_input · retryable: false Die Anfrage hat Sunras eigene Schema- oder Parametervalidierung nicht bestanden. message nennt das betroffene Feld. Was zu tun ist: Korrigieren Sie das genannte Feld. Dieselbe Anfrage wird weiterhin fehlschlagen.

provider_rejected_input

code: invalid_input · retryable: false Der Modell-Provider hat einen oder mehrere Eingabeparameter abgelehnt. Wenn der Provider uns mitteilt, welche, gibt message das wieder; manche Provider melden nur, dass die Eingabe unzulässig war — dann sagen wir genau das, statt zu raten. Was zu tun ist: Prüfen Sie Ihre Parameter gegen das Schema des Modells — ein Wert außerhalb des zulässigen Bereichs, eine nicht unterstützte Kombination, ein Seitenverhältnis oder eine Dauer, die das Modell nicht akzeptiert.

input_fetch_failed

code: invalid_input · retryable: false oder true Eine per URL referenzierte Eingabedatei konnte nicht abgerufen werden. Dies ist die einzige Reason, bei der retryable tatsächlich variiert — lesen Sie also das Feld, statt es anzunehmen:
  • false — der Host hat uns abgewiesen: eine 4xx, eine Adresse, von der wir nicht abrufen dürfen, ein Redirect oder eine Datei über der Größenbegrenzung;
  • true — der Host war kurzzeitig nicht erreichbar: eine 5xx, ein Timeout oder ein DNS-Fehler.
message gibt die von Ihnen übermittelte URL wieder, damit Sie erkennen, welche Eingabe fehlgeschlagen ist — ohne deren Query-String, sodass in einer Presigned URL enthaltene Zugangsdaten niemals an Sie zurückgespiegelt werden:
Was zu tun ist: Ist retryable gleich false, prüfen Sie, ob die URL öffentlich erreichbar ist und ob ein Presigned Link nicht abgelaufen ist. Ist es true, versuchen Sie es erneut.

moderation_blocked

code: unsafe_content · retryable: false Vom Content-Safety-System des Modell-Providers blockiert — entweder der eingehende Prompt und die Eingabemedien oder die erzeugte Ausgabe. Was zu tun ist: Ändern Sie den Prompt oder die Medien. Derselbe Inhalt wird beim erneuten Senden wieder blockiert.

provider_rate_limited

code: service_provider_error · retryable: true Der Modell-Provider drosselt Anfragen. Was zu tun ist: Versuchen Sie es mit Backoff erneut oder leiten Sie auf ein anderes Modell um.

provider_unavailable

code: service_provider_error · retryable: true Der Modell-Provider konnte die Anfrage nicht bedienen. Was zu tun ist: Versuchen Sie es später erneut oder leiten Sie auf ein anderes Modell um.

provider_timeout

code: task_timeout · retryable: true Die Prediction wurde nicht innerhalb der zulässigen Zeit fertig. Was zu tun ist: Versuchen Sie es erneut — eine Phase geringerer Last oder eine kleinere Anfrage (kürzere Dauer, niedrigere Auflösung) verbessert die Chancen.

provider_account_error

code: internal_server_error · retryable: false Unser eigenes Konto beim Modell-Provider hat ein Problem — Abrechnung, Zugangsdaten oder ein dauerhaftes Kontingent. Das liegt an uns, nicht an Ihrer Eingabe. Was zu tun ist: auf Ihrer Seite nichts; ein erneuter Versuch hilft nicht, und wir werden automatisch alarmiert. Leiten Sie auf ein anderes Modell um, wenn Sie die Kapazität sofort brauchen.

endpoint_misconfigured

code: internal_server_error · retryable: false Dieser Modell-Endpunkt ist auf unserer Seite falsch konfiguriert. Was zu tun ist: auf Ihrer Seite nichts; ein erneuter Versuch hilft nicht, und wir werden automatisch alarmiert. Wenden Sie sich bei Dringlichkeit mit der request_id an den Support.

queue_enqueue_failed

code: internal_server_error · retryable: true Die Prediction konnte nicht in die Warteschlange gestellt werden. Was zu tun ist: Senden Sie die Anfrage erneut.

reaped_stalled

code: internal_server_error · retryable: true Die Prediction blieb hängen und wurde beendet. Was zu tun ist: Senden Sie die Anfrage erneut.

Unbekannte Werte

Sowohl code als auch reason sind offene Mengen. Neue Werte kommen hinzu, sobald wir weitere Fehler einordnen — ohne Ankündigung eines Breaking Change. Ihre Integration darf nicht abstürzen, den Fehler nicht verwerfen und die Payload nicht zurückweisen, wenn sie einen ihr unbekannten Wert sieht.
  • Unbekannter reason — behandeln Sie ihn, als wäre reason nicht vorhanden, und entscheiden Sie anhand von retryable (oder dem Standardwert je code). Behalten Sie den Rohwert in Ihren Logs; das ist für den Support der schnellste Weg, den Fehler zu identifizieren.
  • Unbekannter code — behandeln Sie ihn als internal_server_error. Ein Sentinel-Wert lohnt sich namentlich zu kennen: unknown_error_code. Sunra sendet ihn, wenn eine Prediction fehlgeschlagen ist, sich dafür aber keine Einordnung ermitteln ließ.

Hinweis zur Migration: error ist null, wenn kein Fehler vorliegt

Gültig ab 17. August 2026. Das error-Objekt hat auf jedem Kanal genau eine Darstellung. Drei Unterschiede zwischen ihnen sind entfallen:
  • error ist null, wenn die Prediction nicht fehlgeschlagen ist. GET /v1/predictions/{prediction_id} antwortete früher bei jeder erfolgreichen, in der Warteschlange stehenden und abgebrochenen Prediction mit einem leeren Objekt — "error": {}. Jetzt antwortet der Endpunkt mit "error": null, so wie es der Warteschlangen-Status-Endpunkt bereits tat. Wenn Sie auf Leerheit prüfen (Object.keys(response.error).length === 0), ersetzen Sie das durch eine Null-Prüfung (response.error === null).
  • Ein Fehlschlag trägt immer einen nicht leeren code und eine nicht leere message. Wo ein Fehlschlag etwas erfasst hat, das wir nicht einordnen können, erhalten Sie jetzt den Sentinel-Wert unknown_error_code und eine generische Meldung statt eines Feldes, das fehlt, leer oder keine Zeichenkette ist.
  • Als reiner Text erfasste Fehler erreichen Sie als Text. Eine Handvoll Predictions aus dem April 2026 hat ihren Fehler als bloße Zeichenkette gespeichert. GET /v1/predictions/{prediction_id} verwarf ihn früher, und der Warteschlangen-Status-Endpunkt ersetzte ihn durch die Sentinel-Meldung; beide veröffentlichen ihn jetzt als message unter code: "unknown_error_code".
Es wurde nichts entfernt und es kam kein neues Feld hinzu: error war bereits in jeder dieser Antworten enthalten, und nur sein Wert hat sich geändert. Webhook-Zustellungen bleiben unberührt — sie hatten bereits die Form, auf die die anderen Kanäle zusammengelaufen sind — und error fehlt bei einer succeeded-Zustellung weiterhin, statt als null gesendet zu werden. Kompatibilitätsfenster. Es gibt keine Phase mit doppelter Ausgabe; die API hat an diesem Datum aufgehört, "error": {} zu erzeugen. Wenn Sie Payloads erneut abspielen oder verarbeiten, die Sie davor erfasst haben, behandeln Sie null und {} als dasselbe, bis diese gespeicherten Daten abgelaufen sind.

Bevorstehende Änderung: Einige Fehler erhalten einen spezifischeren code

Heute wird ein großer Teil der Fehler als service_provider_error gemeldet, darunter viele, die weder vorübergehend noch vom Provider verschuldet sind. Während wir die Provider nacheinander einordnen, wandern diese Fehler zu dem code, der sie tatsächlich beschreibt:
  • Ein Provider, der Ihre Eingabe deterministisch ablehnt, wird zu invalid_input (zuvor service_provider_error);
  • ein Problem auf Sunras Seite, etwa ein falsch konfigurierter Endpunkt oder unser eigenes Provider-Konto, wird zu internal_server_error (zuvor service_provider_error);
  • eine Eingabedatei, die wir nicht abrufen konnten, wird zu invalid_input (zuvor internal_server_error).
Kein Code wird umbenannt oder entfernt, und es wird kein neuer code-Wert eingeführt — die fünf Werte oben bleiben die vollständige Menge der eingeordneten Codes. Was sich ändert, ist, welchen davon ein bestimmter Fehler erhält, und das geschieht schrittweise, Provider für Provider. Wenn Sie anhand von code verzweigen, ist jetzt ein guter Zeitpunkt, diese Logik auf retryable und reason umzustellen: Beide beschreiben den Fehler direkt und sind von der Neueinordnung nicht betroffen.

API-Anfragefehler