# Feil og ratelimiter
Source: https://nordvec.com/no/docs/guides/errors-and-rate-limits

Den ene feilenveloppen som hvert mislykkede forespørsel returnerer, ratelimit-hodene, og hvordan du kan prøve en skriving på nytt på en trygg måte.



Hvert endepunkt feiler på samme måte, så en klient håndterer feil, ratelimiter og
omforsøk én gang og gjenbruker den koden overalt, inkludert over
[MCP](/docs/guides/mcp).

## Feilkonvolutten [#feilkonvolutten]

Hvert ikke-2xx-svar er ett JSON-objekt:

```json
{
  "defined": false,
  "code": "TOO_MANY_REQUESTS",
  "message": "Too many requests",
  "data": { "reason": "rate_limit.exceeded", "retryAfterMs": 12000 }
}
```

* `code` er HTTP-nivåfeilen, for eksempel `UNAUTHORIZED`, `FORBIDDEN`,
  `NOT_FOUND`, `BAD_REQUEST` eller `TOO_MANY_REQUESTS`.
* `data.reason`, når til stede, er en mer presis maskinlesbar årsak som
  `auth.key_not_found` eller `rate_limit.exceeded`. Forgrening baseres på denne i stedet for på
  `message`, som er for mennesker og kan endre seg.
* `defined` er `true` når operasjonen lister den feilen i
  [API-referansen](/docs/api), og `false` for feil enhver forespørsel kan møte
  (autentisering, ratelimiter, en ukjent rute).
* Et valideringsproblem svarer med `BAD_REQUEST` med problemene i
  `data.formErrors` og `data.fieldErrors`.

Hvert svar inneholder også en `X-Request-ID`. Oppgi den når du kontakter
support, så kan vi finne akkurat den forespørselen.

## Vanlige statuskoder [#vanlige-statuskoder]

| Status | Kode                    | Hva du skal gjøre                                                         |
| ------ | ----------------------- | ------------------------------------------------------------------------- |
| `400`  | `BAD_REQUEST`           | Rett forespørselen; `data.fieldErrors` navngir feltene                    |
| `401`  | `UNAUTHORIZED`          | Send en gyldig nøkkel eller sesjon                                        |
| `403`  | `FORBIDDEN`             | Nøkkelen mangler scopet eller rollen operasjonen trenger                  |
| `404`  | `NOT_FOUND`             | Ressursen finnes ikke, eller du har ikke tilgang til å se den             |
| `409`  | `CONFLICT`              | En duplikat skriving er fortsatt under behandling; prøv igjen om kort tid |
| `413`  | `PAYLOAD_TOO_LARGE`     | Forespørselsteksten er over 1 MB; del en bulk-push i mindre batcher       |
| `422`  | `UNPROCESSABLE_CONTENT` | Forespørselen er velformet, men kan ikke utføres                          |
| `429`  | `TOO_MANY_REQUESTS`     | Vent i `Retry-After`, så prøv igjen                                       |

## Ratelimiter [#ratelimiter]

Hvert svar oppgir grensen det ble telt mot, i to former:

* `X-RateLimit-*`-headerne;
* de IETF-strukturerte feltene `RateLimit` (live-tilstand: `r` er gjenværende forespørsler,
  `t` sekunder til vinduet nullstilles) og `RateLimit-Policy`
  (kvoten: `q` er grensen, `w` vinduet i sekunder).

Et `429` inneholder også `Retry-After` i sekunder og `data.retryAfterMs`. Vent minst så lenge
før neste forespørsel; å prøve igjen tidligere telles og avslås på nytt.

## Sikker omprøving av skriveoperasjoner [#sikker-omprøving-av-skriveoperasjoner]

En skriveoperasjon som lister en `Idempotency-Key`-header i
[API-referansen](/docs/api) kan prøves på nytt uten å utføre arbeidet to ganger. Send
én nøkkel per logisk skriving og gjenta samme nøkkel ved hvert omforsøk:

* samme nøkkel med samme kropp innen 24 timer spiller av det lagrede svaret;
* samme nøkkel med ulik kropp avslås med `422`;
* et duplikat som ankommer mens den første fortsatt kjører får `409`.

En operasjon uten headeren er ikke idempotent, så prøv den bare på nytt når du
vet at det første forsøket ikke ble gjennomført.