Spring til hovedindhold
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:
EndpointHastighedsgrænse
POST /email/find/single10 req/s
POST /email/find/bulk10 req/s
POST /email/verify/single10 req/s
POST /email/verify/bulk10 req/s
POST /phone/single10 req/s
POST /phone/bulk10 req/s
GET-endpoints er ikke hastighedsbegrænsede, så hentning af resultater — for eksempel enkelt e-mailresultat eller bulk-resultater — tæller ikke med i din kvote.
Hastighedsgrænser er pr. API-nøgle og måles i forespørgsler pr. sekund (RPS). Hver API-nøgle har sin egen uafhængige kvote.

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

Når du overskrider hastighedsgrænsen, returnerer API’et et 429 Too Many Requests-svar: 
{
  "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: 
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 og Fejlhåndtering.

​
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.
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.
// ❌ 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 og Verificer e-mails i bulk for at komme i gang.
Polling af GET-endpointet spilder din hastighedsgrænsekvote. Brug webhooks til automatisk at modtage resultater, så snart en søgning eller verifikation er fuldført.
Gem resultater for at undgå overflødige API-kald for den samme kontakt, hvilket også sparer credits.

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

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

​
FAQ

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.
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.
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.
Et 429 Too Many Requests-svar med brødteksten { "message": "Too Many Requests" }. Prøv igen med eksponentiel backoff. Se Fejlhåndtering for detaljer.

​
Næste skridt

Find e-mails i bulk

Kør op til 5.000 e-mailsøgninger i en enkelt forespørgsel for at spare på hastighedsgrænsekvoten.

Webhooks

Modtag resultater automatisk i stedet for at polle GET-endpoints.

Fejlhåndtering

Håndter 429 og andre svar elegant i din integration.

Credits og fakturering

Se, hvordan credits forbruges for hvert endpoint.