> ## Documentation Index > Fetch the complete documentation index at: https://docs.bettertoken.ai/llms.txt > Use this file to discover all available pages before exploring further. # BetterToken-API-Fehler: HTTP-Statuscodes und Limits > Diagnostiziere BetterToken-API-Fehler mit HTTP-Status, Antwort und Anfrage-ID. Behebe Probleme mit Authentifizierung, Anfragelimits, Timeouts und Wiederholungen. 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](https://bettertoken.ai/workspace). Falls du noch keine Modellanfrage erfolgreich ausgeführt hast, beginne mit den [SDK-Beispielen](/de/guides/sdk-examples.md) oder der [Einrichtungsanleitung für dein Tool](/de/ai-tools/overview.md). ## Die Fehlerantwort lesen BetterToken gibt API-Fehler in einer JSON-Struktur zurück. Eine Anfrage ohne Key kann beispielsweise Folgendes liefern: ```json theme={null} { "error": { "code": "", "message": "Token not provided (request id: …)", "type": "new_api_error" } } ``` 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: | Angabe | Was du festhalten solltest | | - | - | | HTTP-Status | Antwortstatus oder Timeout- bzw. Netzwerkausnahme des Clients, falls keine HTTP-Antwort einging | | Antwortinhalt | Fehler-JSON oder anderer zurückgegebener Inhalt ohne geheime Daten | | Anfrage-ID | Kennung in `error.message`, falls vorhanden | | Zeitpunkt | Datum, Uhrzeit und Zeitzone des Versuchs | | Model ID | Exakter als `model` gesendeter Wert | | Base URL | Konfigurierte Base URL und endgültiger Anfragepfad | 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. | Status | Häufige Bedeutung | Zuerst prüfen | Wiederholen? | | - | - | - | - | | `400` | Ungültige Anfrage, ungültiges Feld oder unzulässige Parameterkombination | JSON-Struktur, Pflichtfelder, Modell und Endpunktspezifikation | Zuerst die Anfrage korrigieren | | `401` | Fehlende, ungültige, abgelaufene oder widerrufene Zugangsdaten | Key-Status, Leerzeichen und Authentifizierungsheader des Protokolls | Zuerst die Authentifizierung korrigieren | | `403` | Anfrage abgelehnt | Antwortnachricht, Guthaben, Key-Status und Clientkonfiguration | Zuerst die Ursache der Ablehnung beheben | | `404` | Route oder angeforderte Ressource nicht gefunden | Base URL, doppeltes oder fehlendes `/v1`, endgültiger Pfad und exakte Model ID | Zuerst URL oder Ressource korrigieren | | `408` / Client-Timeout | Der Server erhielt die vollständige Anfrage nicht rechtzeitig oder der Client wartet nicht länger | Ob ein HTTP-Status einging, Timeout-Einstellungen, Netzwerk und Anfragestatus im Dashboard | Vor der Entscheidung den Abschluss prüfen | | `409` / `422`, falls zurückgegeben | Meist ein Konflikt oder nicht verarbeitbarer Inhalt | Antwortdetails und übermittelter Zustand oder Felder | Zuerst die Ursache beheben | | `429` | Ein Limit wurde erreicht | Antwortinhalt und etwaige Wiederholungsheader; siehe [FAQ zur Limitdiagnose](/de/faq/codex/usage-limit-vs-api-rate-limit.md) | Nur bei einem bestätigten vorübergehenden Anfragelimit | | `500` | Serverseitiger Fehler | Anfrageeintrag, Nachricht und Fortbestehen des Fehlers | Begrenzte Wiederholung bei vorübergehendem Fehler | | `502` / `503` | Gateway- oder Upstream-Fehler oder vorübergehende Nichtverfügbarkeit | Antwortinhalt und etwaiger `Retry-After`-Header | Begrenzte Wiederholung bei vorübergehendem Fehler | | `504` | Gateway-Timeout beim Warten auf eine Upstream-Antwort | Dashboard-Eintrag und Abschluss der Anfrage | Vor der Wiederholung den Abschluss prüfen | Bei Protokoll- und Suffixfehlern hilft die [FAQ zur Base URL](/de/faq/model-calling/base-url-config.md). Bei Cache-Fragen nutze die [FAQ zur Cache-Abrechnung](/de/faq/service-assurance/cache-billing.md). ## 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](https://bettertoken.ai/pricing) und ersetze beide Platzhalter. Verwende ein Textmodell, das über [Chat Completions](/de/api-reference/chat-completions.md) verfügbar ist. ```bash theme={null} export BETTERTOKEN_API_KEY="YOUR_API_KEY" export BETTERTOKEN_MODEL_ID="YOUR_MODEL_ID" ``` 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. **Python** ```python theme={null} import json import os import random import time import urllib.error import urllib.request from datetime import datetime, timezone from email.utils import parsedate_to_datetime def retry_after_seconds(value): try: return max(0.0, float(value)) except ValueError: return max(0.0, ( parsedate_to_datetime(value) - datetime.now(timezone.utc) ).total_seconds()) retry_temporary_429 = False # Enable only after diagnosing the returned limit. payload = json.dumps({ "model": os.environ["BETTERTOKEN_MODEL_ID"], "messages": [{"role": "user", "content": "Reply with one word: OK"}], }).encode() for attempt in range(4): request = urllib.request.Request( "https://bettertoken.ai/v1/chat/completions", data=payload, headers={ "Authorization": "Bearer " + os.environ["BETTERTOKEN_API_KEY"], "Content-Type": "application/json", }, ) try: with urllib.request.urlopen(request, timeout=120) as response: print(json.load(response)["choices"][0]["message"]["content"]) break except urllib.error.HTTPError as error: body = error.read().decode("utf-8", errors="replace") retryable = error.code in (500, 502, 503) or ( error.code == 429 and retry_temporary_429 ) if not retryable or attempt == 3: raise RuntimeError(f"HTTP {error.code}: {body}") from error delay = random.uniform(0, min(8.0, 2.0 ** attempt)) retry_after = error.headers.get("Retry-After") if retry_after: delay = max(delay, retry_after_seconds(retry_after)) if delay > 30: raise RuntimeError("Retry-After exceeds this retry budget") from error time.sleep(delay) ``` **JavaScript** ```javascript theme={null} const retryTemporary429 = false; // Enable only after diagnosing the returned limit. const payload = { model: process.env.BETTERTOKEN_MODEL_ID, messages: [{ role: "user", content: "Reply with one word: OK" }], }; for (let attempt = 0; attempt < 4; attempt++) { const response = await fetch("https://bettertoken.ai/v1/chat/completions", { method: "POST", headers: { Authorization: `Bearer ${process.env.BETTERTOKEN_API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify(payload), signal: AbortSignal.timeout(120000), }); const body = await response.text(); if (response.ok) { console.log(JSON.parse(body).choices[0].message.content); break; } const retryable = [500, 502, 503].includes(response.status) || (response.status === 429 && retryTemporary429); if (!retryable || attempt === 3) { throw new Error(`HTTP ${response.status}: ${body}`); } let delay = Math.random() * Math.min(8000, 1000 * 2 ** attempt); const retryAfter = response.headers.get("Retry-After"); if (retryAfter !== null) { const seconds = Number(retryAfter); const wait = Number.isFinite(seconds) ? seconds * 1000 : Date.parse(retryAfter) - Date.now(); if (!Number.isFinite(wait)) throw new Error("Invalid Retry-After header"); delay = Math.max(delay, wait, 0); } if (delay > 30000) throw new Error("Retry-After exceeds this retry budget"); await new Promise(resolve => setTimeout(resolve, delay)); } ``` 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 | Symptom | Anleitung | | - | - | | Authentifizierungs-, URL- oder Modellfehler in Claude Code | [Häufige Fehler bei Claude Code](/de/ai-tools/claude-code.md#common-errors) | | Codex verlangt eine Anmeldung oder ignoriert Provider-Änderungen | [Häufige Fehler bei Codex CLI / App](/de/ai-tools/codex.md#common-errors) | | Cursor-Key lässt sich nicht aktivieren oder integrierte Modelle funktionieren nicht mehr | [Häufige Fehler bei Cursor](/de/ai-tools/cursor.md#common-errors) | | Authentifizierungsfehler, `404` oder Modellfehler in Cline | [Häufige Fehler bei Cline](/de/ai-tools/cline.md#common-errors) | | Provider-, Modell- oder Projektkonfigurationsfehler in OpenCode | [Häufige Fehler bei OpenCode](/de/ai-tools/opencode.md#common-errors) | | Claude Desktop Gateway kann keine Verbindung herstellen | [Häufige Fehler bei Claude Desktop](/de/faq/claude-desktop-bettertoken-api.md#common-errors) | | Nutzungshinweis des offiziellen Codex oder API-Status `429` | [Nutzungslimit und API-Anfragelimit](/de/faq/codex/usage-limit-vs-api-rate-limit.md) | | Änderungen scheinen wirkungslos | [Konfligierende Umgebungsvariablen löschen](/de/best-practices.md#clear-conflicting-environment-variables) | | Abgeschnittene Ausgabe oder Fehler zum Ausgabelimit | [Limits für Ausgabetokens](/de/faq/model-calling/max-tokens.md) | ## 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](/de/faq/codex/usage-limit-vs-api-rate-limit.md), 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](/de/best-practices.md#set-a-generous-timeout) und prüfe die Einstellung anschließend mit einer kleinen Anfrage. ## Weitere Informationen * [SDK-Anfragebeispiele](/de/guides/sdk-examples.md) * [Streaming und Tool-Aufrufe](/de/guides/streaming-and-tool-calling.md) * [API-Referenz](/de/api-reference/introduction.md) * [Unterstützte Tools](/de/ai-tools/overview.md) * [FAQ zur Cache-Abrechnung](/de/faq/service-assurance/cache-billing.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.