Ana içeriğe atla

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.

CometAPI hata işleme, istek yapısı sorunlarını, kimlik doğrulama sorunlarını, path hatalarını ve yeniden denenebilir platform hatalarını birbirinden ayırdığınızda en kolay hale gelir. İsteği düzeltmeniz mi yoksa yeniden denemeniz mi gerektiğine karar vermek için HTTP durumunu, error.code ve error.message birleşimini kullanın.

​
Hızlı ön inceleme

StatusGenellikle ne anlama gelirRetry?İlk işlem
400İstek, normal şekilde işlenmeden önce doğrulamadan geçemedi.Hayırmodel, messages, JSON yapısı ve alan türlerini doğrulayın.
401API anahtarı eksik, hatalı biçimlendirilmiş veya geçersiz.HayırAuthorization: Bearer <COMETAPI_KEY> değerini kontrol edin.
403Erişim engellendi veya mevcut isteğe izin verilmedi.Genellikle hayırBilinen şekilde çalışan bir istekle yeniden deneyin ve önce modele özgü alanları kaldırın.
Path hatasıYanlış base URL veya yanlış endpoint path. Comet üzerinde bu, temiz bir JSON 404 yerine 301 yönlendirmesi veya HTML olarak görünebilir.HayırTam olarak https://api.cometapi.com/v1 kullanın ve hata ayıklama sırasında yönlendirmeleri otomatik takip etmeyi kapatın.
429Hız sınırlaması veya geçici doygunluk.EvetJitter ile exponential backoff kullanın.
500 with error.code: invalid_requestHatalı biçimlendirilmiş bir istek, sunucu durumu yanıtı üzerinden ortaya çıktı.HayırYeniden denemeden önce istek gövdesini düzeltin.
500, 503, 504, 524Platform, sağlayıcı veya zaman aşımı sınıfı hata.EvetBackoff ile yeniden deneyin ve request id bilgisini saklayın.

​
Hata zarfı

Birçok CometAPI hatası bunun gibi bir hata gövdesi kullanır: 
{
	"error": {
		"message": "...",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Bazı yanıtlar code alanını boş bırakır. Durum 500 olduğunda, belirleyici sinyal olarak error.code ve error.message değerlerini dikkate alın.

​
400 Bad Request

Bir 400 genellikle, istek normal şekilde işlenmeden önce istek gövdesinin doğrulamadan geçemediği anlamına gelir. Yaygın nedenler:
  • model gibi zorunlu alanların eksik olması
  • Geçersiz JSON yapısı
  • Yanlış türde bir alan gönderilmesi
  • Seçilen endpoint’in kabul etmediği sağlayıcıya özgü parametrelerin yeniden kullanılması
Bilinen şekilde çalışan minimal bir istekten başlayın, ardından isteğe bağlı alanları tek tek geri ekleyin. Yükü, API referansındaki endpoint şemasıyla karşılaştırın. Bunun gibi minimal bir istek kullanın: 
{
	"model": "your-model-id",
	"messages": [
		{
			"role": "user",
			"content": "Hello"
		}
	]
}
your-model-id değerini CometAPI Models page üzerindeki güncel model ID değerlerinden herhangi biriyle değiştirin. Hatalı biçimlendirilmiş her chat isteğinin 400 döndüreceğini varsaymayın. messages gibi zorunlu chat alanlarının eksik olması, error.code: invalid_request ile birlikte 500 olarak da ortaya çıkabilir.

​
500 Internal Server Error

Çoğu 500 yanıtı bir platform veya sağlayıcı hatasına işaret eder. Chat Completions için bazı hatalı biçimlendirilmiş istekler de 500 olarak görünebilir ve yine de error.code: invalid_request taşıyabilir. Buna bir örnek, messages alanını atlayan bir istektir: 
{
	"error": {
		"message": "field messages is required (request id: ...)",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Bir 500 yanıtında error.code: invalid_request varsa, bunu bir istek sorunu olarak değerlendirin:
  1. İstek gövdesini düzeltin.
  2. Yükü endpoint şemasıyla karşılaştırın.
  3. Yalnızca yükü düzelttikten sonra yeniden deneyin.
Bir 500 yanıtı geçersiz bir isteğe işaret etmiyorsa, request id bilgisini saklayın ve backoff kullanın.

​
401 Invalid Token

Bir token hatası genellikle şöyle görünür: 
{
	"error": {
		"code": "",
		"message": "invalid token (request id: ...)",
		"type": "comet_api_error"
	}
}
Kontrol edilmesi gerekenler:
  1. Header tam olarak Authorization: Bearer <COMETAPI_KEY> olmalıdır.
  2. Uygulamanızın .env, shell geçmişi veya dağıtılmış secret store içinden eski bir key yüklemediğinden emin olun.
  3. Aynı istekte bir key başarısız olurken başka bir key çalışıyorsa, bunu endpoint sorunu değil, token sorunu olarak değerlendirin.

​
403 Forbidden

403 çoğu zaman şu durumlardan biridir:
  • İstek, WAF filtreleme gibi platform taraflı bir kural tarafından engelleniyordur
  • Token veya route, istenen model ya da istek biçimini kullanmaya yetkili değildir
  • Seçilen model, gönderdiğiniz gelişmiş parametrelerden birini reddediyordur
İlk olarak yapılması gerekenler:
  1. Bilinen şekilde çalışan bir model karşısında çok basit bir metin isteğiyle yeniden deneyin.
  2. Gelişmiş alanları ve provider’a özgü parametreleri kaldırın, ardından bunları kademeli olarak geri ekleyin.
  3. Yanıtta bir request id varsa, support ile iletişime geçmeden önce bunu saklayın.
Mesajda group veya channel gibi dahili terimler geçiyorsa, bunları istemci tarafında ilk teşhis edilecek şeyler olarak değil, yönlendirme ayrıntıları olarak değerlendirin. Pratik çözüm yine önce token, model ve istek biçimini doğrulamaktır.

​
Yanlış base URL veya yanlış path

Comet üzerinde bir path hatası şu şekillerde ortaya çıkabilir:
  • Bir yönlendirme
  • İstemciniz yönlendirmeleri takip ediyorsa JSON olmayan bir HTML yanıtı
  • SDK’nız içinde bir ayrıştırma hatası
  • API katmanına temiz şekilde hiç ulaşmayan bir istek
Bu base URL’yi tam olarak kullanın: 
https://api.cometapi.com/v1
Önerilen kontroller:
  1. base URL’nin /v1 içerdiğini doğrulayın.
  2. Endpoint path’in dokümantasyonla birebir eşleştiğini doğrulayın.
  3. Path sorunlarında hata ayıklarken otomatik yönlendirme takibini devre dışı bırakın.

​
413 Request Entity Too Large

413 görüyorsanız, önce bunu bir istek boyutu sorunu olarak ele alın. Yaygın şüpheliler şunlardır:
  • Büyük base64 payload’ları
  • Satır içinde gömülü aşırı büyük görseller veya sesler
  • Çok büyük multipart veya JSON body’leri
Yapılması gerekenler:
  1. Eklenen içeriği küçültün veya sıkıştırın.
  2. Büyük işleri daha küçük isteklere bölün.
  3. Nedenin yalnızca düz metin uzunluğu olduğunu varsaymayın.

​
429 Too Many Requests

429 yeniden denenebilir olarak ele alınmalıdır:
  1. jitter ile exponential backoff kullanın.
  2. Anlık eşzamanlılık miktarını azaltın.
  3. Hangi route ve model’in önce doyuma ulaştığını görebilmek için istek loglamayı açık tutun.
Yeniden kullanılabilir bir retry kalıbı için Chat Completions sayfasındaki backoff örneğine bakın.

​
503, 504, and 524

Bu durum kodları sunucu taraflı veya timeout sınıfı hatalardır. Pratik açıklama:
  • 503: route veya provider servisi geçici olarak kullanılamıyor
  • 504 ve 524: platform, edge veya provider servisi arasında timeout sınıfı hatalar
Yapılması gerekenler:
  1. backoff ile yeniden deneyin.
  2. request id, endpoint, model ve timestamp bilgisini saklayın.
  3. Aynı hata birden fazla yeniden denemede tekrarlanıyorsa, bu bağlamla birlikte support ile iletişime geçin.

​
Destekle iletişime geçmeden önce

Önce şu ayrıntıları toplayın:
  • HTTP yöntemi
  • Endpoint yolu
  • Model ID
  • Temizlenmiş istek gövdesi JSON’ı (çoğu API çağrısı için en faydalı tek öğe budur)
  • Hatalı istek bunları kullandıysa sorgu parametreleri
  • İstemciniz yakaladıysa tam yanıt gövdesi
  • Tam HTTP durum kodu
  • Tam error.message
  • Herhangi bir request id
  • Yaklaşık zaman damgası
  • Aynı isteğin başka bir model veya başka bir token ile çalışıp çalışmadığı
Hatalı route düz bir JSON gövdesi yerine dosya yüklemeleri kabul ediyorsa (görüntü düzenleme, ses yükleme, video üretimi vb.), eşdeğer gönderilen payload’u iletin:
  • Dosyayla birlikte gönderdiğiniz alan adları ve metin değerleri
  • Dosya adı, dosya türü ve yaklaşık dosya boyutu
  • Dosyanın doğrudan mı yüklendiği, URL ile mi referans verildiği yoksa base64 olarak mı gömüldüğü
Bir bug’ı yeniden üretmenin en etkili yolu, tam olarak temizlenmiş istek payload’udur. Çoğu API çağrısı için bu, ham istek gövdesi JSON’ı anlamına gelir. Dosya yükleme route’ları için ise bu, alan listesi ve dosya meta verileri anlamına gelir.
Bu, destek dönüş süresini önemli ölçüde kısaltır.