# Fejl og hastighedsgrænser
Source: https://nordvec.com/da/docs/guides/errors-and-rate-limits

Den ene fejlkuvert, som hvert fejlslagent request returnerer, hastighedsgrænse-headers og hvordan du genforsøger en skrivning sikkert.



Hvert endpoint fejler på samme måde, så en klient håndterer fejl, rategrænser og genforsøg én gang og genbruger den kode overalt, herunder over [MCP](/docs/guides/mcp).

## Fejlkapslen [#fejlkapslen]

Ethvert ikke-2xx-svar er ét JSON-objekt:

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

* `code` er fejlen på HTTP-niveau, for eksempel `UNAUTHORIZED`, `FORBIDDEN`,
  `NOT_FOUND`, `BAD_REQUEST` eller `TOO_MANY_REQUESTS`.
* `data.reason`, når den er til stede, er en mere præcis maskinlæsbar årsag som
  `auth.key_not_found` eller `rate_limit.exceeded`. Forgrén på den i stedet for på
  `message`, som er til mennesker og kan ændre sig.
* `defined` er `true`, når operationen oplister den fejl i
  [API-referencen](/docs/api), og `false` for fejl, som enhver anmodning kan møde
  (autentificering, rategrænser, en ukendt rute).
* Et valideringsfejl svarer med `BAD_REQUEST` og problemerne i
  `data.formErrors` og `data.fieldErrors`.

Hvert svar indeholder også et `X-Request-ID`. Citér det, når du kontakter
support, så kan vi finde den præcise anmodning.

## Almindelige statuskoder [#almindelige-statuskoder]

| Status | Kode                    | Hvad du skal gøre                                                 |
| ------ | ----------------------- | ----------------------------------------------------------------- |
| `400`  | `BAD_REQUEST`           | Ret anmodningen; `data.fieldErrors` angiver felterne              |
| `401`  | `UNAUTHORIZED`          | Send en gyldig nøgle eller session                                |
| `403`  | `FORBIDDEN`             | Nøglen mangler det scope eller den rolle, som operationen kræver  |
| `404`  | `NOT_FOUND`             | Ressourcen findes ikke, eller du har ikke adgang til at se den    |
| `409`  | `CONFLICT`              | En duplikat-skrivning er stadig i gang; prøv igen om kort tid     |
| `413`  | `PAYLOAD_TOO_LARGE`     | Anmodningsbrød er over 1 MB; del en bulk-push op i mindre batches |
| `422`  | `UNPROCESSABLE_CONTENT` | Anmodningen er velformet, men kan ikke anvendes                   |
| `429`  | `TOO_MANY_REQUESTS`     | Vent i `Retry-After`, og prøv derefter igen                       |

## Rategrænser [#rategrænser]

Hvert svar angiver den grænse, som det blev talt op imod, i to former:

* `X-RateLimit-*`-headere;
* de IETF-strukturerede felter `RateLimit` (live-tilstand: `r` er de resterende anmodninger,
  `t` er sekunderne, indtil vinduet nulstilles) og `RateLimit-Policy`
  (kvotaen: `q` er grænsen, `w` er vinduet i sekunder).

Et `429` medfører også `Retry-After` i sekunder og `data.retryAfterMs`. Vent mindst så længe,
før du sender den næste anmodning; et tidligere genforsøg tælles med og
afvises igen.

## Sikker genafsendelse af skrivninger [#sikker-genafsendelse-af-skrivninger]

En skrivningsoperation, der oplister en `Idempotency-Key`-header i
[API-referencen](/docs/api), kan genafsendes uden at udføre arbejdet to gange. Send
én nøgle per logisk skrivning, og gentag den samme nøgle ved hvert genforsøg:

* den samme nøgle med det samme brød inden for 24 timer afspiller det gemte svar;
* den samme nøgle med et andet brød afvises med `422`;
* en duplikat, der ankommer, mens den første stadig kører, får `409`.

En operation uden headeren er ikke idempotent, så genafsend den kun, når du
ved, at det første forsøg ikke blev gennemført.