> ## Documentation Index
> Fetch the complete documentation index at: https://docs.enrow.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Fejlhåndtering

> Håndtér Enrow API-fejl elegant — svarformater, statuskoder, genforsøgslogik og bedste praksis

Enrow API'et signalerer problemer med HTTP-statuskoder og en JSON-fejlbody. Denne guide forklarer fejlsvarformaterne, de mest almindelige fejl og hvordan du retter dem, samt hvordan du bygger pålidelig genforsøgslogik. Se den komplette liste over koder i [Status codes](/da/status-codes).

## Hvordan ser et fejlsvar ud?

De fleste Enrow API-fejl returnerer et simpelt JSON-objekt med et enkelt `message`-felt:

```json theme={null}
{
  "message": "Human-readable error description"
}
```

Den eneste undtagelse er en **insufficient-credit (402)**-fejl på **single**-endpoints (email/phone find single, verify single), som returnerer et `reason`-felt sammen med `success`:

```json theme={null}
{
  "reason": "Insufficient credits",
  "success": false
}
```

Fejlsvar indeholder aldrig felterne `error`, `status` eller `retry_after`. Læs HTTP-statuskoden for at forgrene din logik, og læs `message` (eller `reason`) for den menneskelæsbare beskrivelse.

## Hvad er de mest almindelige fejl, og hvordan retter jeg dem?

Fejlene nedenfor dækker langt størstedelen af mislykkede anmodninger. Hver enkelt kommer med den svarbody, API'et returnerer, og rettelsen.

### Hvorfor får jeg en 400 Bad Request?

En `400` betyder, at anmodningens payload er forkert udformet eller mangler en påkrævet parameter:

```json theme={null}
{
  "message": "both company_domain and company_name are absent, input payload needs at least one of them"
}
```

**Rettelse**: Kontrollér, at du angiver alle påkrævede parametre for endpointet. For eksempel kræver [Find Single Email](/da/api-reference/email-finder/find-single) `fullname` plus enten `company_domain` eller `company_name`.

### Hvorfor får jeg en 401 Unauthorized?

En `401` betyder, at API-nøglen mangler eller er ugyldig:

```json theme={null}
{
  "message": "This apikey is not valid"
}
```

**Rettelse**: Kontrollér, at API-nøglen er korrekt og sendes i `x-api-key`-headeren (ikke `Authorization`). Se [Authentication](/da/authentication) for, hvordan du sender nøglen ved hver anmodning.

### Hvorfor får jeg en 402 Insufficient Credits?

En `402` betyder, at kontoen ikke har nok credits til at køre anmodningen:

```json theme={null}
{
  "reason": "Insufficient credits",
  "success": false
}
```

På **bulk**-endpoints returneres den samme `402` i stedet med den standardiserede `{ "message": "..." }`-form.

**Rettelse**: Tjek credit-saldoen på [Dashboard](https://app.enrow.io) eller via `GET /account/info`. Køb flere credits, eller opgradér abonnementet på [enrow.io/pricing](https://enrow.io/pricing). Se [Credits & billing](/da/credits-billing) for, hvordan credits forbruges pr. endpoint.

### Hvorfor får jeg en 429 Rate Limit Exceeded?

En `429` betyder, at der blev sendt for mange anmodninger inden for et kort tidsrum:

```json theme={null}
{
  "message": "Too Many Requests"
}
```

**Rettelse**: Vent og prøv igen med eksponentiel backoff. Se [Rate limits](/da/rate-limits) for grænserne pr. abonnement.

### Hvorfor får jeg en 500 Internal Server Error?

En `500` betyder, at noget gik galt på Enrows side:

```json theme={null}
{
  "message": "An unexpected error occurred"
}
```

**Rettelse**: Prøv anmodningen igen med backoff. Hvis problemet fortsætter, kontakt [api@enrow.io](mailto:api@enrow.io).

## Hvordan håndterer jeg fejl i kode?

Tjek HTTP-statussen, før du parser succes-bodyen, og kast derefter en fejl, der bærer statuskoden, så din genforsøgslogik kan forgrene sig på den. `message`-feltet indeholder beskrivelsen for de fleste fejl, og `reason` indeholder den for single-endpoint-`402`-svar.

<CodeGroup>
  ```javascript Node.js theme={null}
  async function findEmail(contact) {
    const response = await fetch('https://api.enrow.io/email/find/single', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'x-api-key': process.env.ENROW_API_KEY
      },
      body: JSON.stringify(contact)
    });

    if (!response.ok) {
      const body = await response.json();
      const error = new Error(`Enrow API error ${response.status}: ${body.message || body.reason}`);
      error.status = response.status;
      throw error;
    }

    return await response.json();
  }
  ```

  ```python Python theme={null}
  import requests
  import os

  def find_email(contact):
      response = requests.post(
          "https://api.enrow.io/email/find/single",
          json=contact,
          headers={
              "Content-Type": "application/json",
              "x-api-key": os.getenv("ENROW_API_KEY")
          }
      )

      if not response.ok:
          error = response.json()
          message = error.get("message") or error.get("reason")
          raise Exception(f"Enrow API error {response.status_code}: {message}")

      return response.json()
  ```
</CodeGroup>

## Hvordan prøver jeg mislykkede anmodninger igen?

Prøv kun de fejl igen, der er værd at prøve igen — `429` og `5xx` — og brug eksponentiel backoff mellem forsøgene. Klientfejl i `4xx`-området (undtagen `429`) signalerer et problem med selve anmodningen, så det hjælper ikke at prøve dem igen.

```javascript theme={null}
async function requestWithRetry(fn, maxRetries = 3, baseDelay = 1000) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await fn();
    } catch (error) {
      const isLastAttempt = attempt === maxRetries - 1;

      // Don't retry client errors (except rate limits)
      if (error.status >= 400 && error.status < 500 && error.status !== 429) {
        throw error;
      }

      if (isLastAttempt) throw error;

      const delay = baseDelay * Math.pow(2, attempt);

      await new Promise(resolve => setTimeout(resolve, delay));
    }
  }
}
```

## Bedste praksis

* **Prøv ikke 4xx-fejl igen** (undtagen 429) — ret anmodningen i stedet
* **Prøv 429-fejl igen** — brug eksponentielle forsinkelser som backoff, før du prøver igen
* **Prøv 5xx-fejl igen** — med eksponentiel backoff
* **Brug webhooks** i stedet for polling for at undgå at ramme rate limits unødigt — se [How webhooks work](/da/how-webhooks-work)
* **Log fejl med kontekst** — inkludér endpointet, parametrene og tidsstemplet til fejlfinding

## FAQ

<AccordionGroup>
  <Accordion title="Hvordan skelner jeg en 402 på single- vs. bulk-endpoints?">
    På single-endpoints (email/phone find single, verify single) returnerer en `402` `{ "reason": "Insufficient credits", "success": false }`. På bulk-endpoints returnerer den samme `402` den standardiserede `{ "message": "..." }`-form. Ved at læse både `message` og `reason` (som kodeeksemplerne gør) håndteres begge tilfælde.
  </Accordion>

  <Accordion title="Hvilke fejl bør jeg prøve igen automatisk?">
    Prøv `429`-fejl (rate limit) og `5xx`-fejl (server) igen med eksponentiel backoff. Prøv ikke andre `4xx`-fejl igen, såsom `400`, `401` eller `402` — de indikerer et problem med anmodningen, API-nøglen eller credit-saldoen, som det ikke alene kan løse at prøve igen.
  </Accordion>

  <Accordion title="Findes der en retry_after-header, der fortæller mig, hvor længe jeg skal vente?">
    Nej. Fejlsvar indeholder aldrig felterne `retry_after`, `error` eller `status`. Brug din egen eksponentielle backoff mellem genforsøg. Se [Rate limits](/da/rate-limits) for de grænser, der gælder for dit abonnement.
  </Accordion>

  <Accordion title="Hvor læser jeg fejlmeddelelsen i svaret?">
    For de fleste fejl er beskrivelsen i `message`-feltet. For en insufficient-credit-`402` på et single-endpoint er den i stedet i `reason`-feltet. Forgren altid din logik på HTTP-statuskoden i stedet for at parse meddelelsesteksten.
  </Accordion>
</AccordionGroup>

## Næste skridt

<CardGroup cols={2}>
  <Card title="Status codes" icon="list-check" href="/da/status-codes">
    Den komplette liste over HTTP-statuskoder og deres betydninger.
  </Card>

  <Card title="Rate limits" icon="gauge-high" href="/da/rate-limits">
    Forstå anmodningsgrænserne pr. abonnement for at undgå 429-fejl.
  </Card>

  <Card title="Authentication" icon="key" href="/da/authentication">
    Sådan sender du din API-nøgle i x-api-key-headeren.
  </Card>

  <Card title="Credits & billing" icon="coins" href="/da/credits-billing">
    Se, hvordan credits forbruges for hvert endpoint.
  </Card>
</CardGroup>