Bevor du einen Bug meldest

Wenn etwas nicht funktioniert, ist der schnellste Weg herauszufinden, ob das Problem auf deiner oder unserer Seite liegt, dieselbe Anfrage mit einem anderen Tool auszuführen.

Etwa 9 von 10 Meldungen "API kaputt" entpuppen sich als falsch konfigurierte Basis-URL, ein abgelaufener API-Key, ein falscher Modellname oder ein Request-Body-Format aus einem Tutorial, das drei SDK-Versionen veraltet ist.

Schnell-Selbsttest

Kopiere diesen curl-Befehl in ein Terminal. Ersetze YOUR_KEY durch deinen API-Key aus dem Dashboard und führe ihn aus. Wenn du eine normale Antwort erhältst, sind dein API-Key, das Netzwerk und unser Backend in Ordnung — alles Fehlerhafte liegt dann in deinem Client-Code oder deiner Umgebung.

cURL

curl https://api.airforce/v1/chat/completions \
  -H "Authorization: Bearer sk-air-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4.1-mini",
    "messages": [{"role": "user", "content": "ping"}]
  }'

Schritt-für-Schritt-Checkliste

Ist dein API-Key gültig?

Öffne Dashboard → API Keys und bestätige, dass der Key mit dem übereinstimmt, den dein Code verwendet. Eine häufige Falle ist ein Leerzeichen vor dem Präfix "sk-air-", das beim Kopieren entstanden ist.

Symptom: 401 Unauthorized.

Ist die Basis-URL korrekt?

Die Basis-URL muss https://api.airforce/v1 sein — nicht http, und das Suffix /v1 ist erforderlich. Tutorials, die vor OpenAIs v1-Pfad entstanden sind, lassen ihn manchmal weg.

Symptom: 404 Not Found oder curl hängt.

Ist der Modellname korrekt geschrieben?

Modell-IDs sind case-sensitiv. Besuche die Models-Seite oder rufe GET /v1/models auf, um die genaue ID zu bestätigen. Ein Tippfehler oder ein veraltetes Modell gibt einen klaren Fehler zurück statt "funktioniert, aber falsch".

Symptom: 400 unknown_model oder 404 model_not_found.

Hat der Request-Body die richtige Form?

Chat-Completions verwenden ein messages-Array. Bilder verwenden prompt + n. Audio-TTS verwendet input + voice. Einen chat-förmigen Body an /v1/images/generations zu senden gibt 400 zurück — leicht zu übersehen, wenn man Snippets zwischen Docs kopiert.

Symptom: 400 mit dem betroffenen Feld im Response-Body.

Hast du ein Rate-Limit oder Kontingent erreicht?

429 = zu viele Anfragen in dieser Minute. 402 = dein Plan oder dein Guthaben ist erschöpft. Beides ist im Dashboard ersichtlich. Free-Tier-Anfragen haben separate Limits gegenüber bezahlten Plänen — ein kostenpflichtiges Modell kann problemlos antworten, während ein kostenloses ein Rate-Limit hat.

Symptom: 429 Too Many Requests oder 402 Payment Required.

Ist das Modell gerade verfügbar?

Prüfe die Models-Seite — Provider-Ausfälle werden als "degraded" oder "major outage" angezeigt. Wenn ein Modell ausgefallen ist, während andere funktionieren, handelt es sich um ein provider-seitiges Problem, das wir umrouten — kein Client-Fehler.

Symptom: Ein bestimmtes Modell gibt 5xx zurück, während andere funktionieren.

Was HTTP-Statuscodes bedeuten

Jede Fehlerantwort enthält einen Standard-HTTP-Statuscode. Zu wissen, was jeder Code aussagt, spart ein Ticket.

Wann es wirklich ein Bug ist

Wenn der curl-Selbsttest oben funktioniert, aber dieselbe Anfrage aus deinem Code nicht, liegt das Problem in deinem Client (oder der Bibliothek, die er verwendet). Wenn der Selbsttest selbst mit einem 5xx schlägt fehl oder ein 4xx mit einer Meldung zurückgibt, die nicht zu deiner Anfrage passt, ist das meldungswürdig.

Effektiv melden

Öffne ein Support-Ticket über das Dashboard oder poste im #support auf Discord. Füge Folgendes bei:

• Den vollständigen HTTP-Statuscode und den Response-Body (ggf. auch den cf-ray-Response-Header).
• Ungefähren Zeitstempel in UTC.
• Modellname und welchen Endpunkt du aufgerufen hast.
• Ein minimales cURL, das das Problem reproduziert (echten API-Key maskieren!).
• Ob der Selbsttest oben mit demselben Key bei dir funktioniert.

Im #support auf Discord fragen