Optimiser vos appels API : rate limiting et performance
Apprenez à optimiser vos appels à l'API BCE/KBO : gestion du rate limiting, mise en cache, pagination et bonnes pratiques de performance.
En bref
Pour optimiser vos appels a l'API BCE/KBO, combinez quatre strategies : mettre en cache les fiches d'entreprises (TTL 24h), implementer un retry avec backoff exponentiel sur les erreurs 429, utiliser la pagination pour les recherches a grand volume et controler la concurrence des requetes paralleles. Ces techniques permettent de rester dans les quotas tout en maximisant les performances.
Comprendre le rate limiting
Notre API utilise un système de rate limiting pour garantir un service équitable à tous les utilisateurs. Pour une vue d'ensemble de l'architecture complete, consultez la reference des quotas et du caching pour scaler avec l'API BCE/KBO.
Limites par plan
| Plan | Requêtes/minute | Requêtes/jour |
|---|---|---|
| Gratuit | 10 | 100 |
| Starter | 60 | 5.000 |
| Pro | 300 | 50.000 |
| Enterprise | Sur mesure | Sur mesure |
Headers de réponse
Chaque réponse inclut des headers informatifs :
1 2 3
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1711234567
Stratégie 1 : Mise en cache intelligente
Les données de la BCE ne changent pas fréquemment — voir la liste des endpoints BCE disponibles pour identifier lesquels mettre en cache en priorité. Mettez en cache les résultats :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
import { LRUCache } from class="code-string">'lru-cache';
const cache = new LRUCache<string, any>({
max: 1000,
ttl: 1000 * 60 * 60 * 24, class="code-comment">// 24 heures
});
async function getCompany(bceNumber: string) {
const cached = cache.get(bceNumber);
if (cached) return cached;
const response = await fetch(
class="code-string">`https:class="code-comment">//companybelgium.be/api/companies/${bceNumber}`,
{ headers: { class="code-string">'X-API-Key': apiKey, class="code-string">'X-API-Secret': apiSecret } }
);
const data = await response.json();
cache.set(bceNumber, data);
return data;
}
Stratégie 2 : Retry avec backoff exponentiel
En cas de rate limiting (HTTP 429), implémentez un retry intelligent :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
async function fetchWithRetry(url: string, options: RequestInit, maxRetries = 3) {
for (let attempt = 0; attempt < maxRetries; attempt++) {
const response = await fetch(url, options);
if (response.status === 429) {
const retryAfter = parseInt(response.headers.get(class="code-string">'Retry-After') || class="code-string">'1');
await new Promise(resolve =>
setTimeout(resolve, retryAfter * 1000 * Math.pow(2, attempt))
);
continue;
}
return response;
}
throw new Error(class="code-string">'Nombre maximum de tentatives atteint');
}
Stratégie 3 : Pagination efficace
Pour les recherches retournant de nombreux résultats, utilisez la pagination. Si vous traitez un grand volume d'entreprises par lot, consultez aussi notre guide sur le traitement par lots (batch processing) avec l'API BCE :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
async function searchAllPages(query: string) {
let page = 1;
const allResults = [];
while (true) {
const response = await fetch(
class="code-string">`https:class="code-comment">//companybelgium.be/api/companies/search?q=${query}&page=${page}&limit=50`,
{ headers: { class="code-string">'X-API-Key': apiKey, class="code-string">'X-API-Secret': apiSecret } }
);
const data = await response.json();
allResults.push(...data.results);
if (data.results.length < 50) break;
page++;
}
return allResults;
}
Stratégie 4 : Requêtes parallèles contrôlées
Envoyez plusieurs requêtes en parallèle tout en respectant les limites :
1 2 3 4 5 6 7 8 9 10 11
async function batchFetch(bceNumbers: string[], concurrency = 5) {
const results = [];
for (let i = 0; i < bceNumbers.length; i += concurrency) {
const batch = bceNumbers.slice(i, i + concurrency);
const promises = batch.map(n => getCompany(n));
results.push(...await Promise.all(promises));
}
return results;
}
Conclusion
En combinant cache, retry intelligent, pagination et contrôle de concurrence, vous maximisez les performances de votre intégration tout en respectant les limites de l'API. Pour aller plus loin, découvrez comment sécuriser vos clés API et comment surveiller les changements d'entreprises avec des alertes.
Questions fréquentes
Qu'est-ce que le rate limiting dans l'API BCE/KBO et comment l'eviter ?
Le rate limiting est un mecanisme qui limite le nombre de requetes par minute et par jour selon votre plan (10 req/min et 100 req/jour en gratuit, jusqu'a 300 req/min et 50 000 req/jour en Pro). Pour l'eviter, mettez en cache les fiches d'entreprises avec un TTL de 24 heures, implementez un retry avec backoff exponentiel sur les erreurs 429 et utilisez la concurrence controlee pour les traitements par lots.
Quelle duree de cache recommandez-vous pour les donnees BCE/KBO ?
Pour les fiches d'entreprises (adresse, statut, dirigeants), un TTL de 24 heures est adapte car les donnees sont mises a jour quotidiennement par la BCE. Pour les donnees tres stables comme les libelles NACE ou les formes juridiques, un TTL de 7 jours est raisonnable. Pour les verifications de statut actif/inactif en contexte KYC, privilegiez un TTL de 1 a 4 heures.
Comment implementer un retry efficace sur les erreurs 429 de l'API BCE ?
Lisez le header Retry-After dans la reponse 429 pour connaitre le nombre de secondes d'attente impose. Implementez ensuite un backoff exponentiel : attendez Retry-After * 2 puissance numero_tentative secondes entre chaque essai, avec un maximum de 3 tentatives. Ajoutez un jitter aleatoire de 10 a 30 % pour eviter que tous vos clients ne reessayent en meme temps.
Comment faire des requetes en parallele sur l'API BCE sans depasser les quotas ?
Utilisez une file d'attente de concurrence limitee : envoyez par exemple 5 requetes en parallele, attendez que le lot soit complete, puis passez au suivant. Surveillez en continu le header X-RateLimit-Remaining entre les lots pour adapter dynamiquement la concurrence. Cette approche permet de traiter efficacement des milliers d'entreprises tout en restant dans les limites du plan.
Commentaires
Articles similaires

Belgian Crossroads Bank for Enterprises (BCE/KBO) API : documentation développeur complète en anglais
Documentation développeur en anglais pour l'API de la Banque-Carrefour des Entreprises belge. Vue d'ensemble du registre BCE/KBO, contexte légal, options d'accès, démarrage rapide avec exemples cURL et patterns d'intégration pour les développeurs internationaux.

Rate limits, quotas et caching pour scaler une application BCE/KBO : architecture de référence
Votre app interroge l'API BCE/KBO en volume — comment éviter les 429, maîtriser les coûts et garantir la latence ? Architecture de référence avec cache à plusieurs niveaux, file de requêtes, observabilité et webhooks. Patterns concrets et chiffres à viser.

BCE API endpoints reference : liste complète des routes REST (companies, addresses, NACE, UBO, établissements, Peppol)
Référence technique exhaustive des endpoints REST de l'API Company Belgium : recherche, fiche entreprise, adresses, activités NACE, établissements, dirigeants, UBO, vérification Peppol. Avec schémas de réponse, paramètres et codes d'erreur.
