Naar hoofdinhoud gaan

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-foutafhandeling is het eenvoudigst wanneer je onderscheid maakt tussen problemen met de vorm van de aanvraag, auth-problemen, padfouten en platformfouten die opnieuw geprobeerd kunnen worden. Gebruik de combinatie van HTTP-status, error.code en error.message om te bepalen of je de aanvraag moet corrigeren of opnieuw moet proberen.

​
Snelle triage

StatusWat het meestal betekentOpnieuw proberen?Eerste actie
400Validatie van de aanvraag is mislukt voordat de aanvraag normaal werd verwerkt.NeeValideer model, messages, de JSON-structuur en veldtypen.
401API key ontbreekt, is onjuist gevormd of ongeldig.NeeControleer Authorization: Bearer <COMETAPI_KEY>.
403Toegang is geblokkeerd of de huidige aanvraag was niet toegestaan.Meestal nietProbeer opnieuw met een bekende werkende aanvraag en verwijder eerst modelspecifieke velden.
PadfoutVerkeerde base URL of verkeerd endpoint-pad. 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 exponentiële backoff met jitter.
500 met error.code: invalid_requestEen onjuist gevormde aanvraag kwam naar voren via een serverstatus-response.NeeCorrigeer de request body voordat je opnieuw probeert.
500, 503, 504, 524Platform-, provider- of timeout-klassefout.JaProbeer opnieuw met backoff en bewaar de request id.

​
Error envelope

Veel CometAPI-fouten gebruiken een error body zoals deze: 
{
	"error": {
		"message": "...",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Sommige responses laten code leeg. Wanneer de status 500 is, behandel dan error.code en error.message als het doorslaggevende signaal.

​
400 Bad Request

Een 400 betekent meestal dat validatie van de request body is mislukt voordat de aanvraag normaal kon worden verwerkt. Veelvoorkomende oorzaken:
  • Ontbrekende verplichte velden zoals model
  • Ongeldige JSON-structuur
  • Een veld verzenden met het verkeerde type
  • Providerspecifieke parameters hergebruiken die het geselecteerde endpoint niet accepteert
Begin met een minimale bekende werkende aanvraag en voeg daarna optionele velden één voor één weer toe. Vergelijk de payload met het endpointschema in de API-referentie. Gebruik een minimale aanvraag zoals deze: 
{
	"model": "your-model-id",
	"messages": [
		{
			"role": "user",
			"content": "Hello"
		}
	]
}
Vervang your-model-id door een actueel model ID van de CometAPI Models page. Ga er niet van uit dat elke onjuist gevormde chataanvraag een 400 retourneert. Ontbrekende verplichte chatvelden zoals messages kunnen ook naar voren komen als 500 met error.code: invalid_request.

​
500 Internal Server Error

De meeste 500-responses wijzen op een platform- of providerfout. Voor Chat Completions kunnen sommige onjuist gevormde aanvragen ook naar voren komen als 500, terwijl ze nog steeds error.code: invalid_request bevatten. Eén voorbeeld is een aanvraag waarin messages ontbreekt: 
{
	"error": {
		"message": "field messages is required (request id: ...)",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Als een 500-response error.code: invalid_request heeft, behandel die dan als een aanvraagprobleem:
  1. Corrigeer de request body.
  2. Vergelijk de payload met het endpointschema.
  3. Probeer pas opnieuw nadat je de payload hebt gecorrigeerd.
Als een 500-response niet wijst op een ongeldige aanvraag, bewaar dan de request id en gebruik backoff.

​
401 Invalid Token

Een tokenfout ziet er meestal zo uit: 
{
	"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 key laadt uit .env, shell history of een deployed secret store.
  3. Als de ene key faalt en een andere key werkt voor dezelfde request, behandel dit dan als een tokenprobleem, niet als een endpointprobleem.

​
403 Forbidden

403 is meestal een van deze situaties:
  • De request wordt geblokkeerd door een platform-side regel zoals WAF-filtering
  • De token of route mag het gevraagde model of de requestvorm niet gebruiken
  • Het gekozen model wijst een van de geavanceerde parameters af die je hebt meegegeven
Wat je eerst moet doen:
  1. Probeer opnieuw met een zeer eenvoudige tekstrequest tegen een bekend werkend model.
  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 routingdetails, niet als het eerste wat je vanaf de clientzijde moet diagnosticeren. De praktische oplossing blijft om eerst de token, het model en de requestvorm te valideren.

​
Verkeerde base URL of verkeerd pad

Bij Comet kan een padfout zichtbaar worden als:
  • Een redirect
  • Een niet-JSON HTML-response als je client redirects volgt
  • Een parsefout binnen je SDK
  • Een request die de API-laag nooit goed bereikt
Gebruik exact deze base URL: 
https://api.cometapi.com/v1
Aanbevolen controles:
  1. Bevestig dat de base URL /v1 bevat.
  2. Bevestig dat het endpointpad exact overeenkomt met de documentatie.
  3. Schakel automatisch redirects volgen uit terwijl je padproblemen debugt.

​
413 Request Entity Too Large

Als je 413 ziet, behandel dit dan eerst als een probleem met de requestgrootte. 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

Behandel 429 als retryable:
  1. Gebruik exponentiële backoff met jitter.
  2. Verlaag burst concurrency.
  3. Laat request-logging ingeschakeld 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.

​
503, 504, en 524

Deze statussen zijn server-side of timeout-class failures. Praktische richtlijnen:
  • 503: route of provider service tijdelijk niet beschikbaar
  • 504 en 524: timeout-class failures tussen het platform, de edge of de provider service
Wat je moet doen:
  1. Probeer opnieuw met backoff.
  2. Bewaar het request id, endpoint, model en de timestamp.
  3. Als dezelfde fout zich bij meerdere retries blijft herhalen, neem dan contact op met support met die context.

​
Voordat je contact opneemt met support

Leg eerst deze gegevens vast:
  • HTTP-methode
  • Endpoint-pad
  • Model ID
  • Geschoonde JSON van de request body (dit is voor de meeste API-calls het meest bruikbare onderdeel)
  • 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 tijdstempel
  • Of dezelfde request werkt met een ander model of een andere token
Als de mislukte route bestandsuploads accepteert (beeldbewerking, 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 meegestuurd
  • Bestandsnaam, bestandstype en geschatte bestandsgrootte
  • Of het bestand direct is geüpload, via URL is gerefereerd of als base64 is ingesloten
De meest effectieve manier om een bug te reproduceren is de exacte geschoonde request payload. Voor de meeste API-calls betekent dat de ruwe JSON van de request body. Voor routes met bestandsuploads betekent dat de veldenlijst plus bestandsmetadata.
Dit verkort de afhandelingstijd door support aanzienlijk.