KBO/BCE API optimaliseren: rate limiting en prestaties

In het kort

Om uw aanroepen naar de KBO/BCE API te optimaliseren, combineert u vier strategieen: bedrijfsfiches cachen (TTL 24 uur), retry met exponentieel backoff implementeren bij 429-fouten, paginering gebruiken voor grote zoekopdrachten en de concurrentie van parallelle verzoeken beheersen. Deze technieken houden u binnen de quota terwijl u de prestaties maximaliseert.

Rate limiting begrijpen

Onze API gebruikt een rate limiting systeem om een eerlijke service te garanderen. Raadpleeg de volledige KBO API endpoints-referentie om te weten welke routes het zwaarst worden belast.

Limieten per plan

Plan	Verzoeken/minuut	Verzoeken/dag
Gratis	10	100
Starter	60	5.000
Pro	300	50.000
Enterprise	Op maat	Op maat

Response headers

Elk antwoord bevat informatieve headers:

Code

1
2
3

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1711234567

Strategie 1: Intelligente caching

KBO-gegevens veranderen niet frequent. Cache de resultaten met een TTL van 24 uur. Zie ook de architectuurgids voor rate limits, quota en caching voor productie-inzet.

Strategie 2: Retry met exponentieel backoff

Bij rate limiting (HTTP 429), implementeer intelligente retry met toenemende wachttijden.

Strategie 3: Efficiënte paginering

Gebruik paginering voor zoekopdrachten met veel resultaten. Voor grootschalige bulkverwerking, zie onze gids over batch processing met de KBO API.

Strategie 4: Gecontroleerde parallelle verzoeken

Stuur meerdere verzoeken parallel terwijl u de limieten respecteert.

Conclusie

Door cache, intelligente retry, paginering en concurrency control te combineren, maximaliseert u de prestaties van uw integratie. Vergeet ook niet uw API-sleutels goed te beveiligen.

Veelgestelde vragen

Wat is rate limiting in de KBO/BCE API en hoe vermijdt u het ?

Rate limiting beperkt het aantal verzoeken per minuut en per dag op basis van uw plan (10 req/min en 100 req/dag gratis, tot 300 req/min en 50 000 req/dag in Pro). Om het te vermijden, cachet u bedrijfsfiches met een TTL van 24 uur, implementeert u retry met exponentieel backoff bij 429-fouten en gebruikt u gecontroleerde concurrentie voor bulkverwerking.

Welke cacheduur raadt u aan voor KBO/BCE-gegevens ?

Voor bedrijfsfiches (adres, status, bestuurders) is een TTL van 24 uur geschikt omdat de gegevens dagelijks worden bijgewerkt door de KBO. Voor zeer stabiele gegevens zoals NACE-labels of rechtsvormen is een TTL van 7 dagen redelijk. Voor verificaties van actieve of inactieve status in een KYC-context geeft u de voorkeur aan een TTL van 1 tot 4 uur.

Hoe implementeert u een efficiente retry bij 429-fouten van de KBO API ?

Lees de Retry-After header in het 429-antwoord om het opgelegde aantal wachtseconden te kennen. Implementeer vervolgens exponentieel backoff: wacht Retry-After maal 2 tot de macht van het pogingsnummer seconden tussen elke poging, met maximaal 3 pogingen. Voeg een willekeurige jitter van 10 tot 30 procent toe om te voorkomen dat alle clients tegelijk opnieuw proberen.

Hoe doet u parallelle verzoeken aan de KBO API zonder de quota te overschrijden ?

Gebruik een wachtrij met beperkte concurrentie: stuur bijvoorbeeld 5 verzoeken parallel, wacht tot de batch volledig is en ga dan verder met de volgende. Bewaak voortdurend de X-RateLimit-Remaining header tussen batches om de concurrentie dynamisch aan te passen. Deze aanpak maakt het mogelijk duizenden bedrijven efficiënt te verwerken binnen de planlimieten.