Naar hoofdinhoud gaan
CometAPI-foutafhandeling is het eenvoudigst wanneer je requestproblemen, authenticatieproblemen en opnieuw-probeerbare platformproblemen van elkaar scheidt. Deze pagina is de canonieke CometAPI-foutgids en richt zich eerst op wat je aan de clientzijde kunt verifiëren.
Deze gids is gebaseerd op live controles op de huidige CometAPI API. We hebben 400, 401 en pad-/base URL-fouten direct geverifieerd. We hebben 413, 429, 500, 503, 504 of 524 niet gereproduceerd in begrensde tests, dus de richtlijnen voor die statussen zijn bewust conservatief.

​
Snelle triage

StatusWat het meestal betekentOpnieuw proberen?Eerste actie
400Requestvalidatie is mislukt voordat het request succesvol werd gerouteerd.NeeValideer model, messages, JSON-structuur en veldtypen.
401API-sleutel ontbreekt, is onjuist gevormd of ongeldig.NeeControleer Authorization: Bearer <COMETAPI_KEY>.
403Toegang is geblokkeerd of het huidige request was niet toegestaan.Meestal nietProbeer opnieuw met een bekend werkend request en verwijder eerst modelspecifieke velden.
PadfoutVerkeerde base URL of verkeerd endpointpad. Bij Comet kan dit verschijnen als een 301-redirect of HTML, niet als een nette JSON-404.NeeGebruik exact https://api.cometapi.com/v1 en schakel automatisch redirects volgen uit tijdens het debuggen.
429Rate limiting of tijdelijke verzadiging.JaGebruik exponential backoff met jitter.
500, 503, 504, 524Platform- of timeout-gerelateerde fout.JaProbeer opnieuw met backoff en bewaar het request id.

​
Error Envelope

De huidige JSON-error envelope die door CometAPI wordt teruggegeven, ziet er zo uit: 
{
	"error": {
		"code": "",
		"message": "...",
		"type": "comet_api_error"
	}
}
Veel live foutmeldingen bevatten ook een request id binnen error.message. Bewaar die waarde wanneer je ondersteuning nodig hebt.

​
400 Bad Request

Wat we hebben waargenomen van de live API toen model ontbrak: 
{
	"error": {
		"code": "",
		"message": "model name is required (request id: ...)",
		"type": "comet_api_error"
	}
}
In de praktijk betekent 400 meestal dat de requestbody validatie niet heeft doorstaan voordat het platform deze naar de modelprovider kon routeren. Veelvoorkomende oorzaken:
  • Ontbrekende verplichte velden zoals model of messages
  • Ongeldige JSON-structuur
  • Een veld verzenden met het verkeerde type
  • Providerspecifieke parameters hergebruiken die het geselecteerde endpoint niet accepteert
Wat je moet doen:
  1. Begin met een minimaal, bekend werkend request.
  2. Voeg optionele velden één voor één weer toe.
  3. Vergelijk de requestbody met het endpointschema in de API-referentie.
Minimaal bekend werkend voorbeeld: 
{
	"model": "your-model-id",
	"messages": [
		{
			"role": "user",
			"content": "Hello"
		}
	]
}
Vervang your-model-id door een actuele model-ID van de CometAPI Models page.

​
401 Invalid Token

Wat we hebben waargenomen van de live API met een ongeldige sleutel: 
{
	"error": {
		"code": "",
		"message": "invalid token (request id: ...)",
		"type": "comet_api_error"
	}
}
Wat je moet controleren:
  1. De header moet exact Authorization: Bearer <COMETAPI_KEY> zijn.
  2. Zorg ervoor dat je app geen oude sleutel laadt uit .env, shellgeschiedenis of een gedeployde secret store.
  3. Als één sleutel faalt en een andere sleutel werkt voor hetzelfde request, behandel dit dan als een tokenprobleem, niet als een endpointprobleem.

​
403 Forbidden

We hebben in afgebakende tests geen stabiele 403 gereproduceerd, dus vermijd om één oud berichtsjabloon als het hele verhaal te behandelen. In de huidige Comet-documentatie wordt 403 meestal besproken als een van deze situaties:
  • Het verzoek wordt geblokkeerd door een platformregel, zoals WAF-filtering
  • De token of route mag het aangevraagde model of de aangevraagde request-vorm niet gebruiken
  • Het gekozen model wijst een van de geavanceerde parameters af die je hebt meegestuurd
Wat je eerst moet doen:
  1. Probeer opnieuw met een zeer eenvoudig tekstverzoek tegen een model waarvan bekend is dat het goed werkt.
  2. Verwijder geavanceerde velden en provider-specifieke parameters en voeg ze daarna geleidelijk weer toe.
  3. Als de response een request id bevat, bewaar die dan voordat je contact opneemt met support.
Als het bericht interne termen noemt zoals group of channel, behandel die dan als routeringsdetails, niet als het eerste wat je vanaf de clientzijde moet diagnosticeren. De praktische oplossing blijft om eerst de token, het model en de request-vorm te valideren.

​
Verkeerde Base URL Of Verkeerd Pad

Dit is het gebied waar de oude pagina het minst accuraat was. In live controles tegen de huidige Comet-endpoints:
  • Posten naar https://api.cometapi.com/chat/completions gaf een 301 redirect naar https://www.cometapi.com/chat/completions
  • Posten naar een nep-API-route zoals https://api.cometapi.com/v1/not-a-real-endpoint gaf ook een 301 redirect naar https://www.cometapi.com/v1/not-a-real-endpoint
Dat betekent dat een fout in het pad zichtbaar kan worden als:
  • Een redirect
  • Een niet-JSON HTML-response als je client redirects volgt
  • Een parseerfout binnen je SDK
  • Een request dat de API-laag nooit netjes bereikt
Gebruik deze base URL exact: 
https://api.cometapi.com/v1
Aanbevolen controles:
  1. Bevestig dat de base URL /v1 bevat.
  2. Bevestig dat het endpoint-pad exact overeenkomt met de documentatie.
  3. Schakel het automatisch volgen van redirects uit terwijl je padproblemen debugt.

​
413 Request Entity Too Large

We hebben 413 niet gereproduceerd in een afgebakende test, zelfs niet met een te grote 8 MiB JSON-request body, dus de oude uitleg dat de prompt te lang was, was te beperkt. Als je toch 413 ziet, behandel het dan eerst als een probleem met de request-grootte. Veelvoorkomende verdachten zijn:
  • Grote base64-payloads
  • Te grote afbeeldingen of audio die inline zijn ingesloten
  • Zeer grote multipart- of JSON-bodies
Wat je moet doen:
  1. Verklein of comprimeer bijgevoegde content.
  2. Splits grote taken op in kleinere requests.
  3. Ga er niet van uit dat alleen de lengte van platte tekst de oorzaak is.

​
429 Too Many Requests

We hebben 429 niet gereproduceerd tijdens een afgebakende gelijktijdigheidsproef met 24 parallelle GET /v1/models-requests, dus de exacte drempel hangt duidelijk af van de route, het model en de huidige toestand van het platform. Behandel 429 als opnieuw te proberen:
  1. Gebruik exponential backoff met jitter.
  2. Verminder burst-concurrency.
  3. Laat request-logging aan staan zodat je kunt zien welke route en welk model als eerste verzadigd raken.
Voor een herbruikbaar retry-patroon, zie het backoff-voorbeeld op Chat Completions.

​
500, 503, 504, En 524

We hebben deze statussen niet gereproduceerd in afgebakende tests. Ze moeten worden gedocumenteerd als server-side of timeout-klasse fouten, niet als gebruikersfouten. Praktische richtlijnen:
  • 500: interne platform- of provider-side fout
  • 503: route of provider-service tijdelijk niet beschikbaar
  • 504 en 524: timeout-klasse fouten tussen het platform, de edge of de provider-service
Wat je moet doen:
  1. Probeer opnieuw met backoff.
  2. Bewaar de request id, endpoint, model en timestamp.
  3. Als dezelfde fout zich over meerdere retries blijft herhalen, neem dan contact op met support met die context.

​
Voordat je contact opneemt met support

Verzamel eerst deze gegevens:
  • HTTP-methode
  • Endpoint-pad
  • Modelnaam
  • Geschoonde request body-JSON (dit is voor de meeste API-calls het meest nuttige item)
  • Queryparameters als de mislukte request die gebruikte
  • Exacte response body als je client die heeft vastgelegd
  • Volledige HTTP-status
  • De exacte error.message
  • Eventuele request id
  • Geschatte timestamp
  • Of dezelfde request werkt met een ander model of een andere token
Als de mislukte route file uploads accepteert (image editing, audio-upload, videogeneratie, enz.) in plaats van een gewone JSON-body, stuur dan de equivalente ingediende payload:
  • Veldnamen en tekstwaarden die je naast het bestand hebt verstuurd
  • Bestandsnaam, bestandstype en geschatte bestandsgrootte
  • Of het bestand direct is geüpload, via URL is verwezen, of als base64 is ingesloten
De snelste manier om een bug te reproduceren is de exacte geschoonde request-payload. Voor de meeste API-calls betekent dat de ruwe request body-JSON. Voor routes met file uploads betekent dat de veldlijst plus bestandsmetadata.
Dit verkort de afhandelingstijd van support aanzienlijk.