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
Feilkonvolutt
Mange CometAPI-feil bruker en feilkropp som dette:
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:
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:
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:
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:
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 utilgjengelig504 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.
Sist endret 23. juni 2026
