- 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 daserror-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 einerror-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
Dasselbeerror-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 eine400 mit genau dem Fehler, der dazu geführt hat, unter dem Code auf Anfrageebene PREDICTION_FAILED:
error.codeistPREDICTION_FAILED, ein API-Anfragefehler mit der Bedeutung „die Prediction, deren Ausgabe Sie angefordert haben, hat keine erzeugt“;error.detailsist daserror-Objekt der Prediction selbst — identisch mit dem, was/statusfür dieselbe Anfrage meldet, sodass die beiden Endpunkte sich über die Fehlerursache niemals widersprechen können. Verzweigen Sie übererror.details.reasonunderror.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 Sieretryable. 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: eine4xx, 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: eine5xx, 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:
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
Sowohlcode 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ärereasonnicht vorhanden, und entscheiden Sie anhand vonretryable(oder dem Standardwert jecode). 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 alsinternal_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:
erroristnull, 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
codeund eine nicht leeremessage. Wo ein Fehlschlag etwas erfasst hat, das wir nicht einordnen können, erhalten Sie jetzt den Sentinel-Wertunknown_error_codeund 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 alsmessageuntercode: "unknown_error_code".
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(zuvorservice_provider_error); - ein Problem auf Sunras Seite, etwa ein falsch konfigurierter Endpunkt oder unser eigenes Provider-Konto, wird zu
internal_server_error(zuvorservice_provider_error); - eine Eingabedatei, die wir nicht abrufen konnten, wird zu
invalid_input(zuvorinternal_server_error).
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.