Langsung ke konten utama

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.

Penanganan error CometAPI paling mudah dilakukan ketika Anda memisahkan masalah bentuk request, masalah auth, kesalahan path, dan kegagalan platform yang bisa di-retry. Gunakan kombinasi status HTTP, error.code, dan error.message untuk memutuskan apakah request perlu diperbaiki atau di-retry.

​
Triage cepat

StatusApa yang biasanya berartiRetry?Tindakan pertama
400Validasi request gagal sebelum request diproses secara normal.TidakValidasi model, messages, bentuk JSON, dan tipe field.
401API key tidak ada, malformed, atau tidak valid.TidakPeriksa Authorization: Bearer <COMETAPI_KEY>.
403Akses diblokir atau request saat ini tidak diizinkan.Biasanya tidakRetry dengan request known-good dan hapus field khusus model terlebih dahulu.
Path mistakeBase URL salah atau path endpoint salah. Di Comet hal ini bisa muncul sebagai redirect 301 atau HTML, bukan JSON 404 yang bersih.TidakGunakan https://api.cometapi.com/v1 secara persis dan nonaktifkan auto-follow redirects saat debugging.
429Rate limiting atau saturasi sementara.YaGunakan exponential backoff dengan jitter.
500 with error.code: invalid_requestRequest yang malformed muncul melalui respons status server.TidakPerbaiki body request sebelum retry.
500, 503, 504, 524Kegagalan platform, provider, atau kelas timeout.YaRetry dengan backoff dan simpan request id.

​
Error envelope

Banyak kegagalan CometAPI menggunakan body error seperti ini: 
{
	"error": {
		"message": "...",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Beberapa respons membiarkan code kosong. Ketika statusnya 500, perlakukan error.code dan error.message sebagai sinyal penentu.

​
400 Bad Request

400 biasanya berarti body request gagal divalidasi sebelum request dapat diproses secara normal. Penyebab umum:
  • Field wajib seperti model tidak ada
  • Bentuk JSON tidak valid
  • Mengirim field dengan tipe yang salah
  • Menggunakan ulang parameter khusus provider yang tidak diterima endpoint yang dipilih
Mulailah dari request minimal yang known-good, lalu tambahkan kembali field opsional satu per satu. Bandingkan payload dengan schema endpoint di referensi API. Gunakan request minimal seperti ini: 
{
	"model": "your-model-id",
	"messages": [
		{
			"role": "user",
			"content": "Hello"
		}
	]
}
Ganti your-model-id dengan model ID saat ini apa pun dari halaman Models CometAPI. Jangan berasumsi bahwa setiap chat request yang malformed akan mengembalikan 400. Field chat wajib yang tidak ada seperti messages juga dapat muncul sebagai 500 dengan error.code: invalid_request.

​
500 Internal Server Error

Sebagian besar respons 500 menunjukkan kegagalan platform atau provider. Untuk Chat Completions, beberapa request yang malformed juga dapat muncul sebagai 500 sambil tetap membawa error.code: invalid_request. Salah satu contohnya adalah request yang menghilangkan messages: 
{
	"error": {
		"message": "field messages is required (request id: ...)",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Jika respons 500 memiliki error.code: invalid_request, perlakukan itu sebagai masalah request:
  1. Perbaiki body request.
  2. Bandingkan payload dengan schema endpoint.
  3. Retry hanya setelah payload diperbaiki.
Jika respons 500 tidak mengarah ke request yang tidak valid, simpan request id dan gunakan backoff.

​
401 Token Tidak Valid

Kegagalan token biasanya terlihat seperti ini: 
{
	"error": {
		"code": "",
		"message": "invalid token (request id: ...)",
		"type": "comet_api_error"
	}
}
Yang perlu diperiksa:
  1. Header harus persis Authorization: Bearer <COMETAPI_KEY>.
  2. Pastikan aplikasi Anda tidak memuat key lama dari .env, riwayat shell, atau secret store yang sudah di-deploy.
  3. Jika satu key gagal dan key lain berhasil pada request yang sama, anggap ini sebagai masalah token, bukan masalah endpoint.

​
403 Forbidden

403 paling sering merupakan salah satu dari situasi berikut:
  • Request diblokir oleh aturan sisi platform seperti pemfilteran WAF
  • Token atau route tidak diizinkan menggunakan model atau bentuk request yang diminta
  • Model yang dipilih menolak salah satu parameter lanjutan yang Anda kirim
Yang harus dilakukan terlebih dahulu:
  1. Coba lagi dengan request teks yang sangat sederhana terhadap model yang diketahui berfungsi baik.
  2. Hapus field lanjutan dan parameter khusus provider, lalu tambahkan kembali secara bertahap.
  3. Jika respons menyertakan request id, simpan itu sebelum menghubungi dukungan.
Jika pesan menyebut istilah internal seperti group atau channel, anggap itu sebagai detail routing, bukan sebagai hal pertama yang harus didiagnosis dari sisi klien. Perbaikan praktisnya tetap memvalidasi token, model, dan bentuk request terlebih dahulu.

​
Base URL salah atau path salah

Di Comet, kesalahan path dapat muncul sebagai:
  • Redirect
  • Respons HTML non-JSON jika klien Anda mengikuti redirect
  • Error parsing di dalam SDK Anda
  • Request yang tidak pernah mencapai layer API dengan benar
Gunakan base URL ini persis: 
https://api.cometapi.com/v1
Pemeriksaan yang direkomendasikan:
  1. Pastikan base URL menyertakan /v1.
  2. Pastikan path endpoint sama persis dengan dokumentasi.
  3. Nonaktifkan mengikuti redirect otomatis saat men-debug masalah path.

​
413 Request Entity Too Large

Jika Anda melihat 413, anggap dulu ini sebagai masalah ukuran request. Penyebab umum meliputi:
  • Payload base64 yang besar
  • Gambar atau audio berukuran terlalu besar yang disematkan secara inline
  • Body multipart atau JSON yang sangat besar
Yang harus dilakukan:
  1. Kurangi atau kompres konten yang dilampirkan.
  2. Bagi job besar menjadi request-request yang lebih kecil.
  3. Jangan berasumsi bahwa panjang teks biasa adalah satu-satunya penyebab.

​
429 Too Many Requests

Anggap 429 sebagai bisa dicoba ulang:
  1. Gunakan exponential backoff dengan jitter.
  2. Kurangi konkurensi burst.
  3. Tetap aktifkan logging request agar Anda bisa melihat route dan model mana yang lebih dulu mencapai saturasi.
Untuk pola retry yang dapat digunakan kembali, lihat contoh backoff di Chat Completions.

​
503, 504, dan 524

Status-status ini adalah kegagalan sisi server atau kelas timeout. Panduan praktis:
  • 503: route atau layanan provider sementara tidak tersedia
  • 504 dan 524: kegagalan kelas timeout antara platform, edge, atau layanan provider
Yang harus dilakukan:
  1. Coba lagi dengan backoff.
  2. Simpan request id, endpoint, model, dan timestamp.
  3. Jika kegagalan yang sama berulang di beberapa retry, hubungi dukungan dengan konteks tersebut.

​
Sebelum Anda menghubungi dukungan

Kumpulkan detail berikut terlebih dahulu:
  • Metode HTTP
  • Path endpoint
  • Model ID
  • JSON body request yang telah disanitasi (ini adalah item tunggal yang paling berguna untuk sebagian besar panggilan API)
  • Parameter query jika request yang gagal menggunakannya
  • Body response yang persis jika client Anda menangkapnya
  • Status HTTP lengkap
  • error.message yang persis
  • request id apa pun
  • Perkiraan timestamp
  • Apakah request yang sama berfungsi dengan model lain atau token lain
Jika route yang gagal menerima unggahan file (pengeditan gambar, unggahan audio, pembuatan video, dll.) alih-alih body JSON biasa, kirim payload setara yang dikirimkan:
  • Nama field dan nilai teks yang Anda kirim bersama file
  • Nama file, tipe file, dan perkiraan ukuran file
  • Apakah file diunggah secara langsung, dirujuk melalui URL, atau disematkan sebagai base64
Cara paling efektif untuk mereproduksi bug adalah payload request yang telah disanitasi secara persis. Untuk sebagian besar panggilan API, itu berarti JSON body request mentah. Untuk route unggahan file, itu berarti daftar field ditambah metadata file.
Ini secara signifikan mempercepat waktu penanganan dukungan.