> ## 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.

# Håndter feilkoder

> Bruk denne veiledningen til å klassifisere CometAPI-feilsvar og bruke retry- eller utbedringstrinn for vanlige forespørselsfeil.

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:

```json theme={null}
{
	"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:

```json theme={null}
{
	"model": "your-model-id",
	"messages": [
		{
			"role": "user",
			"content": "Hello"
		}
	]
}
```

Bytt ut `your-model-id` med en aktuell model ID fra [CometAPI Models page](/no/overview/models).

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`:

```json theme={null}
{
	"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 body-en i forespørselen.
2. Sammenlign payload-en med endpoint-skjemaet.
3. 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:

```json theme={null}
{
	"error": {
		"code": "",
		"message": "invalid token (request id: ...)",
		"type": "comet_api_error"
	}
}
```

Dette bør du sjekke:

1. Headeren må være nøyaktig `Authorization: Bearer $COMETAPI_KEY`.
2. Forsikre deg om at appen din ikke laster inn en gammel nøkkel fra `.env`, shell-historikk eller en distribuert hemmelighetslagring.
3. 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:

1. Prøv på nytt med en helt enkel tekst-request mot en kjent fungerende modell.
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.

<Warning>
  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.
</Warning>

## 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:

```text theme={null}
https://api.cometapi.com/v1
```

Anbefalte kontroller:

1. Bekreft at base URL-en inkluderer `/v1`.
2. Bekreft at endpoint-stien samsvarer nøyaktig med dokumentasjonen.
3. 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:

1. Reduser eller komprimer vedlagt innhold.
2. Del store jobber opp i mindre requests.
3. 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:

1. Bruk eksponentiell backoff med jitter.
2. Reduser burst-konkurrens.
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](/api/text/chat).

## `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:

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 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

<Warning>
  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.
</Warning>

Dette forkorter behandlingstiden hos support betydelig.