Zum Hauptinhalt springen
Diagnostiziere einen BetterToken-API-Fehler anhand von HTTP-Status und Antwortinhalt gemeinsam. Notiere die Anfrage-ID aus error.message, behebe Authentifizierungs- oder Konfigurationsfehler vor dem erneuten Senden und wiederhole nur als vorübergehend erkannte Fehler.

Vor der Fehlersuche

Halte Model ID, Base URL und die fehlgeschlagene Antwort bereit. Prüfe den Key-Status und das aktuelle Guthaben im BetterToken-Dashboard. Falls du noch keine Modellanfrage erfolgreich ausgeführt hast, beginne mit den SDK-Beispielen oder der Einrichtungsanleitung für dein Tool.

Die Fehlerantwort lesen

BetterToken gibt API-Fehler in einer JSON-Struktur zurück. Eine Anfrage ohne Key kann beispielsweise Folgendes liefern:
Lies error.message auch dann, wenn error.code leer ist. Die Anfrage-ID in dieser Nachricht hilft, den fehlgeschlagenen Versuch zuzuordnen. Eine Anfrage an /v1/models ohne Key liefert 401; sie prüft nicht, ob dein Modell eine Antwort generieren kann. Notiere diese Angaben, bevor du den Support kontaktierst: Dein BetterToken API Key gehört nicht in Screenshots, Supportnachrichten oder geteilte Protokolle.

Den HTTP-Status prüfen

Die Tabelle verwendet allgemeine HTTP- und API-Bedeutungen sowie die verlinkten Einrichtungshinweise. Sie ist keine Liste BetterToken-spezifischer Fehlercodes; lies die tatsächliche Antwort, bevor du eine Lösung wählst. Bei Protokoll- und Suffixfehlern hilft die FAQ zur Base URL. Bei Cache-Fragen nutze die FAQ zur Cache-Abrechnung.

Vorübergehende Fehler erneut versuchen

Nutze nach einem bestätigten vorübergehenden 429 oder Serverfehler exponentiell steigende Wartezeiten mit Zufallsanteil und festen Grenzen. Beachte Retry-After, falls vorhanden. Überschreitet der Wert dein Wiederholungsbudget, beende die Schleife und warte außerhalb davon. SDK-Wiederholungen und deine eigene Schleife teilen sich die maximale Zahl der Versuche. Deaktiviere deshalb SDK-Wiederholungen, wenn du eine eigene Regelung implementierst. Wiederhole Fehler mit 400, 401, 403 sowie Guthaben- oder Konfigurationsfehler nicht unverändert. Ein Client-Timeout oder unterbrochener Stream beweist nicht, dass die Anfrage vor der Verarbeitung fehlgeschlagen ist. Prüfe zuerst das Dashboard, besonders bei der Bildgenerierung oder Abläufen, die eine Aktion doppelt ausführen könnten. Die folgenden Beispiele senden eine Chat-Completions-Anfrage ohne Streaming mit höchstens vier Versuchen. Sie wiederholen die HTTP-Statuscodes 500, 502 und 503. Wiederholungen bei 429 bleiben deaktiviert, bis du ein vorübergehendes Anfragelimit bestätigt hast. Bei Timeouts, Netzwerkausnahmen und 504 stoppen die Beispiele, damit du den Abschluss prüfen kannst. Die maximale Wartezeit beträgt 30 Sekunden pro Wiederholung.

Die Anfrage vorbereiten

Kopiere eine aktuelle Model ID aus der model plaza und ersetze beide Platzhalter. Verwende ein Textmodell, das über Chat Completions verfügbar ist.
Das Python-Beispiel nutzt die Standardbibliothek. Speichere das JavaScript-Beispiel als .mjs-Datei und führe es mit einer Node.js-Version aus, die fetch und AbortSignal.timeout bereitstellt.
Wenn der Antwortinhalt auf ein dauerhaftes Konfigurations-, Guthaben- oder Zugriffsproblem hinweist, beende die Schleife und behebe es, auch wenn der Status allein eine Wiederholung nahelegt. Passe dieses kurze Textbeispiel an die Abschlussprüfungen deiner Anwendung an, bevor du es für andere Vorgänge nutzt.

Die passende Anleitung zum Symptom finden

Die Lösung bestätigen

Sende eine kurze, unkritische Anfrage mit demselben Client, derselben Base URL und derselben Model ID wie beim Fehler. Prüfe die normale Antwort und suche den passenden Eintrag im Dashboard. Kontrolliere Modell, Status, Tokenverbrauch und Kosten, bevor du einen größeren Workflow fortsetzt.

Häufige Fragen

Muss ich bei jedem 429 warten und es erneut versuchen?

Nutze die FAQ zur Diagnose von Nutzungslimits, um die nächsten Prüfungen und die Eignung einer Wiederholung für deine Antwort zu bestimmen.

Sollte ich nach einem Fehler den Timeout erhöhen?

Prüfe zuerst, ob dein Client, ein Proxy oder eine Upstream-Anfrage nicht länger gewartet hat. Nutze die Timeout-Hinweise und prüfe die Einstellung anschließend mit einer kleinen Anfrage.

Weitere Informationen