Feilkoder og håndtering

Feilsøk mislykkede CometAPI-forespørsler med verifisert veiledning for 400, 401 og sti-feil, samt praktisk håndtering av 403, 429 og feil i timeout-klassen.

Feilhåndtering i CometAPI er enklest når du skiller mellom forespørselsproblemer, autentiseringsproblemer og plattformproblemer som kan prøves på nytt. Denne siden er den kanoniske feilguiden for CometAPI og fokuserer på det du først kan verifisere fra klientsiden.

Denne guiden er basert på live-sjekker mot det nåværende CometAPI API-et. Vi verifiserte 400, 401 og feil med sti/base URL direkte. Vi reproducerte ikke 413, 429, 500, 503, 504 eller 524 i avgrensede tester, så veiledningen for disse statuskodene er med vilje konservativ.

​

Rask feilsøking

Status	Hva det vanligvis betyr	Prøv på nytt?	Første tiltak
400	Validering av forespørselen mislyktes før forespørselen ble routet riktig.	Nei	Valider model, messages, JSON-struktur og felttyper.
401	API-nøkkelen mangler, er feilformatert eller ugyldig.	Nei	Sjekk Authorization: Bearer <COMETAPI_KEY>.
403	Tilgang ble blokkert, eller den nåværende forespørselen var ikke tillatt.	Vanligvis nei	Prøv på nytt med en kjent fungerende forespørsel, og fjern modellspesifikke felt først.
Feil sti	Feil base URL eller feil endpoint-sti. På Comet kan dette vises som en 301-videresending eller HTML, ikke en ren JSON-404.	Nei	Bruk https://api.cometapi.com/v1 nøyaktig, og deaktiver automatisk videresendingsfølging under feilsøking.
429	Rate limiting eller midlertidig overbelastning.	Ja	Bruk eksponentiell backoff med jitter.
500, 503, 504, 524	Plattformfeil eller feil i timeout-klassen.	Ja	Prøv på nytt med backoff og behold request id.

​

Feilkonvolutt

Den nåværende JSON-feilkonvolutten som returneres av CometAPI ser slik ut:

{
	"error": {
		"code": "",
		"message": "...",
		"type": "comet_api_error"
	}
}

Mange live-feilmeldinger inkluderer også en request id inne i error.message. Lagre denne verdien når du trenger support.

​

400 Bad Request

Dette observerte vi fra live-API-et da model var utelatt:

{
	"error": {
		"code": "",
		"message": "model name is required (request id: ...)",
		"type": "comet_api_error"
	}
}

I praksis betyr 400 vanligvis at forespørselskroppen ikke besto valideringen før plattformen kunne route den til modellleverandøren.

Vanlige årsaker:

• Manglende påkrevde felt som model eller messages
• Ugyldig JSON-struktur
• Sending av et felt med feil type
• Gjenbruk av leverandørspesifikke parametere som det valgte endpoint-et ikke godtar

Hva du bør gjøre:

1. Start med en minimal, kjent fungerende forespørsel.
2. Legg til valgfrie felt igjen ett etter ett.
3. Sammenlign forespørselskroppen med endpoint-skjemaet i API-referansen.

Minimalt kjent fungerende eksempel:

{
	"model": "your-model-id",
	"messages": [
		{
			"role": "user",
			"content": "Hello"
		}
	]
}

Erstatt your-model-id med en aktuell modell-ID fra CometAPI Models page.

​

401 Invalid Token

Dette observerte vi fra live-API-et med en ugyldig nøkkel:

{
	"error": {
		"code": "",
		"message": "invalid token (request id: ...)",
		"type": "comet_api_error"
	}
}

Hva du bør sjekke:

1. Headeren må være nøyaktig Authorization: Bearer <COMETAPI_KEY>.
2. Sørg for at appen din ikke laster inn en gammel nøkkel fra .env, shell-historikk eller en distribuert secret store.
3. Hvis én nøkkel feiler og en annen nøkkel fungerer på samme forespørsel, bør du behandle dette som et token-problem, ikke et endpoint-problem.

​

403 Forbidden

Vi reproduserte ikke en stabil 403 i avgrensede tester, så unngå å behandle én enkelt gammel meldingsmal som hele forklaringen.

I den nåværende Comet-dokumentasjonen omtales 403 oftest som én av disse situasjonene:

• Forespørselen blokkeres av en regel på plattform-siden, som WAF-filtrering
• Token eller rute har ikke tillatelse til å bruke den forespurte modellen eller forespørselsformen
• Den valgte modellen avviser én av de avanserte parameterne du sendte

Hva du bør gjøre først:

1. Prøv på nytt med en svært enkel tekstforespørsel mot en kjent, fungerende modell.
2. Fjern avanserte felt og leverandørspesifikke parametere, og legg dem deretter gradvis tilbake.
3. Hvis svaret inneholder en request id, ta vare på den før du kontakter support.

Hvis meldingen nevner interne termer som group eller channel, bør du behandle disse som rutingsdetaljer, ikke som det første du skal diagnostisere fra klientsiden. Den praktiske løsningen er fortsatt å validere token, model og forespørselsformen først.

​

Feil Base URL eller feil sti

Dette er området der den gamle siden var minst presis.

I live-sjekker mot de nåværende Comet-endepunktene:

• Posting til https://api.cometapi.com/chat/completions returnerte en 301-videresending til https://www.cometapi.com/chat/completions
• Posting til en falsk API-rute som https://api.cometapi.com/v1/not-a-real-endpoint returnerte også en 301-videresending til https://www.cometapi.com/v1/not-a-real-endpoint

Det betyr at en feil i stien kan vise seg som:

• En videresending
• Et ikke-JSON HTML-svar hvis klienten din følger videresendinger
• En parsefeil i SDK-en din
• En forespørsel som aldri når API-laget på en ryddig måte

Bruk denne Base URL-en nøyaktig:

https://api.cometapi.com/v1

Anbefalte sjekker:

1. Bekreft at Base URL-en inkluderer /v1.
2. Bekreft at endepunktstien samsvarer nøyaktig med dokumentasjonen.
3. Deaktiver automatisk følge av videresendinger mens du feilsøker stiproblemer.

​

413 Request Entity Too Large

Vi reproduserte ikke 413 i en avgrenset test, selv med en overdimensjonert 8 MiB JSON request body, så den gamle forklaringen om at prompt var for lang, var for snever.

Hvis du faktisk ser 413, bør du først behandle det som et problem med forespørselsstørrelse. Vanlige årsaker er:

• Store base64-payloads
• Overdimensjonerte bilder eller lyd som er lagt inn inline
• Svært store multipart- eller JSON-kropper

Hva du bør gjøre:

1. Reduser eller komprimer vedlagt innhold.
2. Del store jobber opp i mindre forespørsler.
3. Ikke anta at lengden på ren tekst er den eneste årsaken.

​

429 Too Many Requests

Vi reproduserte ikke 429 under en avgrenset samtidighetsmåling med 24 parallelle GET /v1/models-forespørsler, så den nøyaktige terskelen avhenger tydeligvis av ruten, modellen og plattformens nåværende tilstand.

Behandle 429 som noe det kan prøves på nytt med:

1. Bruk eksponentiell backoff med jitter.
2. Reduser burst-samtidighet.
3. Hold forespørselslogging aktivert slik at du kan se hvilken rute og modell som mettes først.

For et gjenbrukbart mønster for retry, se backoff-eksempelet på Chat Completions.

​

500, 503, 504, og 524

Vi reproduserte ikke disse statuskodene i avgrensede tester. De bør dokumenteres som feil på serversiden eller timeout-relaterte feil, ikke som brukerfeil.

Praktisk veiledning:

• 500: intern feil på plattform- eller leverandørsiden
• 503: ruten eller leverandørtjenesten er midlertidig utilgjengelig
• 504 og 524: timeout-relaterte feil mellom plattformen, edge eller leverandørtjenesten

Hva du bør gjøre:

1. Prøv på nytt med backoff.
2. Ta vare på request id, endepunkt, model og tidsstempel.
3. Hvis den samme feilen gjentar seg over flere forsøk, kontakt support med denne konteksten.

​

Før du kontakter support

Samle disse detaljene først:

• HTTP-metode
• Endpoint-sti
• Modellnavn
• Sanitisert request body JSON (dette er det klart mest nyttige elementet for de fleste API-kall)
• Query-parametere hvis den feilede requesten brukte dem
• Eksakt response body hvis klienten din fanget den opp
• Full HTTP-status
• Den eksakte error.message
• Eventuell request id
• Omtrentlig tidsstempel
• Om den samme requesten fungerer med en annen modell eller en annen token

Hvis ruten som feiler godtar filopplastinger (bilderedigering, lydopplasting, videogenerering osv.) i stedet for en vanlig JSON-body, send den tilsvarende innsendte payloaden:

• Feltnavn og tekstverdier du sendte sammen med filen
• Filnavn, filtype og omtrentlig filstørrelse
• Om filen ble lastet opp direkte, referert med URL eller bygget inn som base64

Den raskeste måten å reprodusere en bug på er den eksakte sanitiserte request-payloaden. For de fleste API-kall betyr det den rå request body JSON. For ruter med filopplasting betyr det feltlisten pluss filmetadata.

Dette forkorter supportens behandlingstid betydelig.