Hopp til hovedinnhold

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.

Feilhåndtering i CometAPI er enklest når du skiller mellom problemer med forespørselens struktur, auth-problemer, path-feil 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

StatusHva det vanligvis betyrPrøve på nytt?Første handling
400Validering av forespørselen mislyktes før forespørselen ble behandlet normalt.NeiValider model, messages, JSON-struktur og felttyper.
401API-nøkkelen mangler, er feilformatert eller ugyldig.NeiSjekk Authorization: Bearer <COMETAPI_KEY>.
403Tilgang ble blokkert eller den gjeldende forespørselen var ikke tillatt.Vanligvis neiPrøv på nytt med en kjent fungerende forespørsel og fjern modellspesifikke felt først.
Path-feilFeil base URL eller feil endpoint-path. I Comet kan dette vises som en 301-videresending eller HTML, ikke en ren JSON-404.NeiBruk https://api.cometapi.com/v1 nøyaktig og deaktiver automatisk videresendingsfølging under feilsøking.
429Rate limiting eller midlertidig metning.JaBruk eksponentiell backoff med jitter.
500 med error.code: invalid_requestEn feilformatert forespørsel kom frem som et svar med serverstatus.NeiRett forespørselens body før du prøver på nytt.
500, 503, 504, 524Plattformsvikt, leverandørsvikt eller timeout-feil.JaPrøv på nytt med backoff og behold request id.

​
Feilkonvolutt

Mange CometAPI-feil bruker en feilkropp som denne: 
{
	"error": {
		"message": "...",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Noen svar lar code stå tom. Når statusen er 500, bør du bruke error.code og error.message som det avgjørende signalet.

​
400 Bad Request

En 400 betyr vanligvis at forespørselens body ikke besto validering før forespørselen kunne behandles normalt. Vanlige årsaker:
  • Manglende påkrevde 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 fungerende forespørsel, og legg deretter til valgfrie felt igjen ett etter ett. 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"
		}
	]
}
Erstatt your-model-id med en gjeldende model ID fra CometAPI Models page. Ikke anta at alle feilformaterte chat-forespørsler returnerer 400. Manglende påkrevde chat-felt som messages kan også komme frem 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 feilformaterte forespørsler også komme frem som 500 samtidig som de fortsatt inneholder error.code: invalid_request. Et 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:
  1. Rett forespørselens body.
  2. Sammenlign payload-en med endpoint-skjemaet.
  3. Prøv på nytt først etter at payload-en er korrigert.
Hvis et 500-svar ikke peker på en ugyldig forespørsel, behold request id og bruk backoff.

​
401 Invalid Token

En tokenfeil ser vanligvis slik ut: 
{
	"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 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 request, behandle dette som et token-problem, ikke et endpoint-problem.

​
403 Forbidden

403 er oftest én av disse situasjonene:
  • Requesten blokkeres av en regel på plattform-siden, for eksempel WAF-filtrering
  • Tokenet eller ruten har ikke tillatelse til å bruke den forespurte modellen eller request-formen
  • Den valgte modellen avviser én av de avanserte parameterne du sendte inn
Hva du bør gjøre først:
  1. Prøv igjen med en veldig enkel tekst-request mot en modell du vet fungerer.
  2. Fjern avanserte felt og providerspesifikke parametere, og legg dem deretter tilbake gradvis.
  3. 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 rutingsdetaljer, ikke som det første du skal feilsøke fra klientsiden. Den praktiske løsningen er fortsatt å validere tokenet, modellen og request-formen først.

​
Feil base URL eller feil path

På Comet kan en feil i pathen vise seg som:
  • En redirect
  • En HTML-respons som ikke er JSON hvis klienten din følger redirects
  • En parse-feil 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:
  1. Bekreft at base URL-en inkluderer /v1.
  2. Bekreft at endpoint-pathen samsvarer nøyaktig med dokumentasjonen.
  3. Deaktiver automatisk redirect-følging mens du feilsøker path-problemer.

​
413 Request Entity Too Large

Hvis du ser 413, bør du først behandle det som et problem med request-størrelse. Vanlige årsaker er:
  • Store base64-payloads
  • Overdimensjonerte bilder eller lyd som er bygget inn inline
  • Svært store multipart- eller JSON-bodyer
Hva du bør gjøre:
  1. Reduser eller komprimer vedlagt innhold.
  2. Del opp store jobber i mindre requests.
  3. Ikke anta at lengden på ren tekst er den eneste årsaken.

​
429 Too Many Requests

Behandle 429 som noe som kan prøves på nytt:
  1. Bruk eksponentiell backoff med jitter.
  2. Reduser burst-samtidighet.
  3. 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 server-side eller timeout-relaterte feil. Praktisk veiledning:
  • 503: rute- eller provider-tjeneste er midlertidig utilgjengelig
  • 504 og 524: timeout-relaterte feil mellom plattformen, edge eller provider-tjenesten
Hva du bør gjøre:
  1. Prøv igjen med backoff.
  2. Ta vare på request id, endpoint, model og tidsstempel.
  3. Hvis den samme feilen gjentar seg på tvers av flere retries, kontakt support med denne konteksten.

​
Før du kontakter support

Samle inn disse opplysningene først:
  • HTTP-metode
  • Endpoint-sti
  • Model ID
  • Sanitert request body JSON (dette er det klart mest nyttige enkeltpunktet for de fleste API-kall)
  • Query-parametere hvis den mislykkede 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 innsendingens payload:
  • 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 lagt inn som base64
Den mest effektive måten å gjenskape en bug på er den eksakte saniterte 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.