Przejdź do głównej treści

Documentation Index

Fetch the complete documentation index at: https://apidoc.cometapi.com/llms.txt

Use this file to discover all available pages before exploring further.

Obsługa błędów w CometAPI jest najprostsza, gdy rozdzielisz problemy z kształtem żądania, problemy z autoryzacją, błędy ścieżki oraz błędy platformy nadające się do ponowienia. Użyj kombinacji statusu HTTP, error.code i error.message, aby zdecydować, czy poprawić żądanie, czy ponowić próbę.

​
Szybka diagnostyka

StatusCo zwykle oznaczaPonowić?Pierwsze działanie
400Walidacja żądania nie powiodła się, zanim żądanie zostało normalnie przetworzone.NieZweryfikuj model, messages, strukturę JSON i typy pól.
401Klucz API jest brakujący, nieprawidłowo sformatowany lub nieważny.NieSprawdź Authorization: Bearer <COMETAPI_KEY>.
403Dostęp został zablokowany lub bieżące żądanie nie było dozwolone.Zwykle niePonów próbę z minimalnym, poprawnym żądaniem i najpierw usuń pola specyficzne dla modelu.
Path mistakeNieprawidłowy base URL lub nieprawidłowa ścieżka endpointu. W Comet może to objawiać się jako przekierowanie 301 lub HTML, a nie czysty JSON 404.NieUżyj dokładnie https://api.cometapi.com/v1 i wyłącz automatyczne podążanie za przekierowaniami podczas debugowania.
429Ograniczanie liczby żądań lub tymczasowe przeciążenie.TakUżyj exponential backoff z jitterem.
500 with error.code: invalid_requestNieprawidłowo sformułowane żądanie zostało zwrócone przez odpowiedź ze statusem serwera.NiePopraw treść żądania przed ponowieniem próby.
500, 503, 504, 524Błąd platformy, dostawcy lub klasy timeout.TakPonów próbę z backoff i zachowaj request id.

​
Obwiednia błędu

Wiele błędów CometAPI używa treści błędu w takiej postaci: 
{
	"error": {
		"message": "...",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Niektóre odpowiedzi pozostawiają code puste. Gdy status to 500, traktuj error.code i error.message jako sygnał decydujący.

​
400 Bad Request

400 zwykle oznacza, że treść żądania nie przeszła walidacji, zanim żądanie mogło zostać normalnie przetworzone. Typowe przyczyny:
  • Brak wymaganych pól, takich jak model
  • Nieprawidłowa struktura JSON
  • Wysłanie pola z nieprawidłowym typem
  • Ponowne użycie parametrów specyficznych dla dostawcy, których wybrany endpoint nie akceptuje
Zacznij od minimalnego, poprawnego żądania, a następnie dodawaj opcjonalne pola z powrotem jedno po drugim. Porównaj payload ze schematem endpointu w dokumentacji API. Użyj minimalnego żądania takiego jak to: 
{
	"model": "your-model-id",
	"messages": [
		{
			"role": "user",
			"content": "Hello"
		}
	]
}
Zastąp your-model-id dowolnym aktualnym model ID ze strony modeli CometAPI. Nie zakładaj, że każde nieprawidłowe żądanie chat zwraca 400. Brak wymaganych pól chat, takich jak messages, może również pojawić się jako 500 z error.code: invalid_request.

​
500 Internal Server Error

Większość odpowiedzi 500 wskazuje na błąd platformy lub dostawcy. W przypadku Chat Completions niektóre nieprawidłowe żądania mogą również pojawiać się jako 500, nadal zawierając error.code: invalid_request. Jednym z przykładów jest żądanie, które pomija messages: 
{
	"error": {
		"message": "field messages is required (request id: ...)",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Jeśli odpowiedź 500 ma error.code: invalid_request, traktuj ją jako problem z żądaniem:
  1. Popraw treść żądania.
  2. Porównaj payload ze schematem endpointu.
  3. Ponów próbę dopiero po poprawieniu payload.
Jeśli odpowiedź 500 nie wskazuje na nieprawidłowe żądanie, zachowaj request id i użyj backoff.

​
401 Invalid Token

Błąd tokenu zwykle wygląda tak: 
{
	"error": {
		"code": "",
		"message": "invalid token (request id: ...)",
		"type": "comet_api_error"
	}
}
Co sprawdzić:
  1. Nagłówek musi mieć dokładnie postać Authorization: Bearer <COMETAPI_KEY>.
  2. Upewnij się, że aplikacja nie ładuje starego klucza z .env, historii shella lub wdrożonego magazynu sekretów.
  3. Jeśli jeden klucz nie działa, a inny działa dla tego samego żądania, traktuj to jako problem z tokenem, a nie z endpointem.

​
403 Forbidden

403 najczęściej oznacza jedną z tych sytuacji:
  • Żądanie jest blokowane przez regułę po stronie platformy, taką jak filtrowanie WAF
  • Token lub trasa nie mają uprawnień do użycia żądanego modelu albo kształtu żądania
  • Wybrany model odrzuca jeden z zaawansowanych parametrów, które przekazano
Co zrobić najpierw:
  1. Spróbuj ponownie z bardzo prostym żądaniem tekstowym skierowanym do modelu, o którym wiadomo, że działa poprawnie.
  2. Usuń zaawansowane pola i parametry specyficzne dla providera, a następnie dodawaj je z powrotem stopniowo.
  3. Jeśli odpowiedź zawiera request id, zachowaj je przed skontaktowaniem się ze wsparciem.
Jeśli komunikat wspomina o wewnętrznych terminach, takich jak group lub channel, traktuj je jako szczegóły routingu, a nie jako pierwszą rzecz do diagnozowania po stronie klienta. Praktycznym rozwiązaniem nadal jest najpierw zweryfikowanie tokenu, modelu i kształtu żądania.

​
Nieprawidłowy base URL lub nieprawidłowa ścieżka

W Comet błąd ścieżki może objawiać się jako:
  • Przekierowanie
  • Odpowiedź HTML niebędąca JSON-em, jeśli klient podąża za przekierowaniami
  • Błąd parsowania w SDK
  • Żądanie, które nigdy nie dociera poprawnie do warstwy API
Użyj dokładnie tego base URL: 
https://api.cometapi.com/v1
Zalecane kontrole:
  1. Potwierdź, że base URL zawiera /v1.
  2. Potwierdź, że ścieżka endpointu dokładnie odpowiada dokumentacji.
  3. Wyłącz automatyczne podążanie za przekierowaniami podczas debugowania problemów ze ścieżką.

​
413 Request Entity Too Large

Jeśli widzisz 413, najpierw traktuj to jako problem z rozmiarem żądania. Typowe przyczyny to:
  • Duże ładunki base64
  • Zbyt duże obrazy lub audio osadzone inline
  • Bardzo duże ciała żądań multipart lub JSON
Co zrobić:
  1. Zmniejsz lub skompresuj dołączoną zawartość.
  2. Podziel duże zadania na mniejsze żądania.
  3. Nie zakładaj, że jedyną przyczyną jest długość zwykłego tekstu.

​
429 Too Many Requests

429 należy traktować jako błąd, po którym można ponowić próbę:
  1. Użyj exponential backoff z jitter.
  2. Zmniejsz współbieżność burstów.
  3. Pozostaw włączone logowanie żądań, aby widzieć, która trasa i który model nasycają się jako pierwsze.
Aby zobaczyć wzorzec ponawiania prób do wielokrotnego użycia, zobacz przykład backoff na stronie Chat Completions.

​
503, 504, and 524

Te statusy to błędy po stronie serwera lub klasy timeout. Praktyczne wskazówki:
  • 503: trasa lub usługa providera jest tymczasowo niedostępna
  • 504 i 524: błędy klasy timeout między platformą, warstwą edge lub usługą providera
Co zrobić:
  1. Ponów próbę z backoff.
  2. Zachowaj request id, endpoint, model i znacznik czasu.
  3. Jeśli ten sam błąd powtarza się przy wielu ponowieniach, skontaktuj się ze wsparciem, przekazując ten kontekst.

​
Zanim skontaktujesz się ze wsparciem

Najpierw zbierz te informacje:
  • Metoda HTTP
  • Ścieżka endpointu
  • Model ID
  • Oczyszczony JSON treści żądania (to pojedynczy najbardziej przydatny element w przypadku większości wywołań API)
  • Parametry zapytania, jeśli nieudane żądanie ich używało
  • Dokładna treść odpowiedzi, jeśli Twój klient ją przechwycił
  • Pełny status HTTP
  • Dokładne error.message
  • Dowolne request id
  • Przybliżony znacznik czasu
  • Czy to samo żądanie działa z innym modelem lub innym tokenem
Jeśli problematyczna ścieżka akceptuje przesyłanie plików (edycja obrazów, przesyłanie audio, generowanie wideo itp.) zamiast zwykłej treści JSON, wyślij równoważny przesłany payload:
  • Nazwy pól i wartości tekstowe, które zostały wysłane razem z plikiem
  • Nazwa pliku, typ pliku i przybliżony rozmiar pliku
  • Czy plik został przesłany bezpośrednio, wskazany przez URL czy osadzony jako base64
Najskuteczniejszym sposobem odtworzenia błędu jest dokładny oczyszczony payload żądania. W przypadku większości wywołań API oznacza to surowy JSON treści żądania. W przypadku ścieżek z przesyłaniem plików oznacza to listę pól oraz metadane pliku.
To znacząco skraca czas obsługi przez wsparcie.