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

# Hastighedsgrænser

> Enrow API-hastighedsgrænser pr. API-nøgle, 429-svaret, og hvordan du håndterer throttling med backoff og bulk-endpoints

Enrow API anvender hastighedsgrænser for at sikre fair brug og opretholde servicekvaliteten. Grænsen er den samme på tværs af alle endpoints og alle abonnementer, den håndhæves **pr. API-nøgle**, og den måles i **forespørgsler pr. sekund (RPS)**. Denne side forklarer standardgrænserne, hvad der sker, når du overskrider dem, og hvordan du holder dig inden for kvoten, når du skalerer op.

## Hvad er standardhastighedsgrænserne?

Hvert POST-endpoint tillader **10 forespørgsler pr. sekund** pr. API-nøgle. Grænsen er identisk på tværs af alle endpoints og alle abonnementer:

| Endpoint                    | Hastighedsgrænse |
| --------------------------- | ---------------- |
| `POST /email/find/single`   | 10 req/s         |
| `POST /email/find/bulk`     | 10 req/s         |
| `POST /email/verify/single` | 10 req/s         |
| `POST /email/verify/bulk`   | 10 req/s         |
| `POST /phone/single`        | 10 req/s         |
| `POST /phone/bulk`          | 10 req/s         |

GET-endpoints er ikke hastighedsbegrænsede, så hentning af resultater — for eksempel [enkelt e-mailresultat](/da/api-reference/email-finder/get-single-result) eller [bulk-resultater](/da/api-reference/email-finder/get-bulk-results) — tæller ikke med i din kvote.

<Note>
  Hastighedsgrænser er **pr. API-nøgle** og måles i **forespørgsler pr. sekund** (RPS). Hver [API-nøgle](/da/authentication) har sin egen uafhængige kvote.
</Note>

## Hvad sker der, når jeg overskrider hastighedsgrænsen?

Når du overskrider hastighedsgrænsen, returnerer API'et et `429 Too Many Requests`-svar:

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

Den anbefalede måde at håndtere en `429` på er at implementere eksponentiel backoff — vent en progressivt længere forsinkelse før hvert nyt forsøg, så API-nøglen har tid til at falde tilbage under grænsen:

```javascript theme={null}
async function requestWithRetry(url, options, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);

    if (response.status === 429) {
      const delay = Math.pow(2, attempt) * 1000;
      await new Promise(resolve => setTimeout(resolve, delay));
      continue;
    }

    return response;
  }

  throw new Error('Max retries exceeded');
}
```

For den fulde liste over svarkoder, og hvordan du håndterer dem, se [Statuskoder](/da/status-codes) og [Fejlhåndtering](/da/error-handling).

## Hvordan kan jeg undgå at ramme hastighedsgrænsen?

Den mest effektive måde at holde sig inden for kvoten på er at sende færre, større forespørgsler og at modtage resultater gennem webhooks i stedet for polling.

<AccordionGroup>
  <Accordion title="Brug bulk-endpoints">
    I stedet for at lave 100 enkelte forespørgsler kan du lave 1 bulk-forespørgsel (op til 5.000 elementer for e-mail, 3.000 for telefon). En enkelt bulk-POST tæller som 1 forespørgsel mod din hastighedsgrænse.

    ```javascript theme={null}
    // ❌ 100 requests = 10 seconds at 10 RPS
    for (const contact of contacts) {
      await findEmail(contact);
    }

    // ✅ 1 request
    await findEmailsBulk(contacts);
    ```

    Se [Find e-mails i bulk](/da/api-reference/email-finder/find-bulk) og [Verificer e-mails i bulk](/da/api-reference/email-verifier/verify-bulk) for at komme i gang.
  </Accordion>

  <Accordion title="Brug webhooks i stedet for polling">
    Polling af GET-endpointet spilder din hastighedsgrænsekvote. Brug [webhooks](/da/how-webhooks-work) til automatisk at modtage resultater, så snart en søgning eller verifikation er fuldført.
  </Accordion>

  <Accordion title="Cache resultater">
    Gem resultater for at undgå overflødige API-kald for den samme kontakt, hvilket også sparer [credits](/da/credits-billing).
  </Accordion>
</AccordionGroup>

## Kan jeg få højere hastighedsgrænser?

Ja. Enrow kan øge din RPS fra sag til sag. Kontakt os på [api@enrow.io](mailto:api@enrow.io) med din use case og forventede volumen.

## FAQ

<AccordionGroup>
  <Accordion title="Deles hastighedsgrænser på tværs af endpoints?">
    Nej. Grænsen på 10 req/s gælder uafhængigt for hvert POST-endpoint, og kvoten spores **pr. API-nøgle** frem for pr. konto.
  </Accordion>

  <Accordion title="Tæller GET-forespørgsler mod hastighedsgrænsen?">
    Nej. GET-endpoints er ikke hastighedsbegrænsede, så polling efter resultater forbruger ikke din RPS-kvote. Når det er sagt, er webhooks stadig at foretrække frem for hyppig polling.
  </Accordion>

  <Accordion title="Tæller en bulk-forespørgsel som én forespørgsel?">
    Ja. En enkelt bulk-POST tæller som 1 forespørgsel mod din hastighedsgrænse, selvom den kan indeholde op til 5.000 elementer for e-mail eller 3.000 for telefon.
  </Accordion>

  <Accordion title="Hvilken statuskode signalerer en hastighedsgrænsefejl?">
    Et `429 Too Many Requests`-svar med brødteksten `{ "message": "Too Many Requests" }`. Prøv igen med eksponentiel backoff. Se [Fejlhåndtering](/da/error-handling) for detaljer.
  </Accordion>
</AccordionGroup>

## Næste skridt

<CardGroup cols={2}>
  <Card title="Find e-mails i bulk" icon="layer-group" href="/da/api-reference/email-finder/find-bulk">
    Kør op til 5.000 e-mailsøgninger i en enkelt forespørgsel for at spare på hastighedsgrænsekvoten.
  </Card>

  <Card title="Webhooks" icon="bell" href="/da/how-webhooks-work">
    Modtag resultater automatisk i stedet for at polle GET-endpoints.
  </Card>

  <Card title="Fejlhåndtering" icon="triangle-exclamation" href="/da/error-handling">
    Håndter 429 og andre svar elegant i din integration.
  </Card>

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