Håndter feilkoder

Feilhåndtering i CometAPI er enklest når du skiller mellom problemer med forespørselsformatet, autentiseringsproblemer, feil i path, og plattformsfeil som kan forsøkes på nytt. Bruk kombinasjonen av HTTP-status, error.code og error.message for å avgjøre om du skal rette forespørselen eller prøve på nytt.

Rask triage

Status	Hva det vanligvis betyr	Retry?	Første handling
`400`	Validering av forespørselen mislyktes før forespørselen ble behandlet normalt.	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 gyldig forespørsel og fjern modelspecifikke felt først.
Path-feil	Feil base URL eller feil endpoint-path. 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 slå av automatisk videresendingsfølging under feilsøking.
`429`	Rate limiting eller midlertidig metning.	Ja	Bruk eksponentiell backoff med jitter.
`500` med `error.code: invalid_request`	En feilformatert forespørsel kom til syne gjennom et svar med serverstatus.	Nei	Rett forespørselens body før du prøver på nytt.
`500`, `503`, `504`, `524`	Plattform-, leverandør- eller timeout-feil.	Ja	Prøv på nytt med backoff og behold request id.

Feilkonvolutt

Mange CometAPI-feil bruker en feilkropp som dette:

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

Noen svar lar code stå tom. Når statusen er 500, behandle error.code og error.message som det avgjørende signalet.

`400 Bad Request`

En 400 betyr vanligvis at body-en i forespørselen ikke besto validering før forespørselen kunne behandles normalt. Vanlige årsaker:

Manglende obligatoriske felt som model
Ugyldig JSON-struktur
Sending av et felt med feil type
Gjenbruk av leverandørspesifikke parametere som det valgte endpoint-et ikke godtar

Start med en minimal kjent gyldig forespørsel, og legg deretter tilbake valgfrie felt ett om gangen. Sammenlign payload-en med endpoint-skjemaet i API-referansen. Bruk en minimal forespørsel som denne:

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

Bytt ut your-model-id med en aktuell model ID fra CometAPI Models page. Ikke anta at hver feilformatert chat-forespørsel returnerer 400. Manglende obligatoriske chat-felt som messages kan også vises som 500 med error.code: invalid_request.

`500 Internal Server Error`

De fleste 500-svar indikerer en plattform- eller leverandørfeil. For Chat Completions kan noen feilformatert forespørsler også vises som 500 samtidig som de fortsatt har error.code: invalid_request. Ett eksempel er en forespørsel som utelater messages:

{
	"error": {
		"message": "field messages is required (request id: ...)",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}

Hvis et 500-svar har error.code: invalid_request, behandle det som et problem med forespørselen:

Rett body-en i forespørselen.
Sammenlign payload-en med endpoint-skjemaet.
Prøv på nytt først etter at du har korrigert payload-en.

Hvis et 500-svar ikke peker på en ugyldig forespørsel, behold request id og bruk backoff.

`401 Ugyldig token`

En tokenfeil ser vanligvis slik ut:

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

Dette bør du sjekke:

Headeren må være nøyaktig Authorization: Bearer $COMETAPI_KEY.
Forsikre deg om at appen din ikke laster inn en gammel nøkkel fra .env, shell-historikk eller en distribuert hemmelighetslagring.
Hvis én nøkkel feiler og en annen nøkkel fungerer på samme request, behandle dette som et tokenproblem, ikke et endpoint-problem.

`403 Forbidden`

403 er som oftest én av disse situasjonene:

Requesten blokkeres av en regel på plattform-siden, for eksempel WAF-filtrering
Tokenen eller ruten har ikke tillatelse til å bruke den forespurte modellen eller request-formen
Den valgte modellen avviser én av de avanserte parameterne du sendte

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

Prøv på nytt med en helt enkel tekst-request mot en kjent fungerende modell.
Fjern avanserte felt og providerspesifikke parametere, og legg dem deretter tilbake gradvis.
Hvis responsen 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 dem som rutingdetaljer, ikke som det første du skal diagnostisere fra klientsiden. Den praktiske løsningen er fortsatt å validere token, modell og request-form først.

Feil base URL eller feil sti

På Comet kan en feil i stien vise seg som:

En omdirigering
En ikke-JSON HTML-respons hvis klienten din følger omdirigeringer
En parsefeil inne i SDK-en din
En request som aldri når API-laget på en ren måte

Bruk denne base URL-en nøyaktig:

https://api.cometapi.com/v1

Anbefalte kontroller:

Bekreft at base URL-en inkluderer /v1.
Bekreft at endpoint-stien samsvarer nøyaktig med dokumentasjonen.
Deaktiver automatisk følger av omdirigeringer mens du feilsøker stiproblemer.

`413 Request Entity Too Large`

Hvis du ser 413, behandle det først som et problem med request-størrelse. Vanlige årsaker er:

Store base64-payloads
Overdimensjonerte bilder eller lyd bygget inn inline
Svært store multipart- eller JSON-kropper

Dette bør du gjøre:

Reduser eller komprimer vedlagt innhold.
Del store jobber opp i mindre requests.
Ikke anta at lengden på ren tekst er den eneste årsaken.

`429 Too Many Requests`

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

Bruk eksponentiell backoff med jitter.
Reduser burst-konkurrens.
Hold request-logging aktivert slik at du kan se hvilken rute og modell som mettes først.

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

`503`, `504` og `524`

Disse statusene er feil på serversiden eller feil i timeout-klassen. Praktisk veiledning:

503: rute- eller provider-tjeneste er midlertidig utilgjengelig
504 og 524: feil i timeout-klassen mellom plattformen, edge eller provider-tjenesten

Dette bør du gjøre:

Prøv igjen med backoff.
Ta vare på request id, endpoint, model og tidsstempel.
Hvis den samme feilen gjentar seg på tvers av flere retry-forsøk, kontakt support med denne konteksten.

Før du kontakter support

Samle disse opplysningene først:

HTTP-metode
Endpoint-sti
model ID
Sanert request body-JSON (dette er det mest nyttige enkeltpunktet for de fleste API-kall)
Query-parametere hvis den feilende requesten brukte dem
Nøyaktig response body hvis klienten din fanget den opp
Full HTTP-status
Den nøyaktige 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 payloaden som ble sendt inn:

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

Den mest effektive måten å gjenskape en bug på er den nøyaktige sanerte request-payloaden. For de fleste API-kall betyr det den rå request body-JSON-en. For ruter med filopplasting betyr det feltlisten pluss filmetadata.

Dette forkorter behandlingstiden hos support betydelig.

Start her

Hurtigstarter for modell-API-er

Kjerneguider for API

Biblioteker

Feil

Priser og fakturering

Support

Rask triage

Feilkonvolutt

`400 Bad Request`

`500 Internal Server Error`

`401 Ugyldig token`

`403 Forbidden`

Feil base URL eller feil sti

`413 Request Entity Too Large`

`429 Too Many Requests`

`503`, `504` og `524`

Før du kontakter support

​Rask triage

​Feilkonvolutt

​400 Bad Request

​500 Internal Server Error

​401 Ugyldig token

​403 Forbidden

​Feil base URL eller feil sti

​413 Request Entity Too Large

​429 Too Many Requests

​503, 504 og 524

​Før du kontakter support

Rask triage

Feilkonvolutt

`400 Bad Request`

`500 Internal Server Error`

`401 Ugyldig token`

`403 Forbidden`

Feil base URL eller feil sti

`413 Request Entity Too Large`

`429 Too Many Requests`

`503`, `504` og `524`

Før du kontakter support