Optimize BCE/KBO API calls: rate limiting guide

In brief

To optimize your BCE/KBO API calls, combine four strategies: cache company records (24h TTL), implement retry with exponential backoff on 429 errors, use pagination for high-volume searches and control the concurrency of parallel requests. These techniques keep you within your quota while maximizing performance.

Understanding rate limiting

Our API uses a rate limiting system to ensure fair service for all users. See the full BCE API endpoints reference to identify which routes consume the most quota.

Limits by plan

Plan	Requests/minute	Requests/day
Free	10	100
Starter	60	5,000
Pro	300	50,000
Enterprise	Custom	Custom

Response headers

Each response includes informative headers:

Code

1
2
3

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

Strategy 1: Smart caching

BCE data doesn't change frequently. Cache results with a 24-hour TTL. See the rate limits, quotas and caching architecture guide for production deployment patterns.

Strategy 2: Retry with exponential backoff

On rate limiting (HTTP 429), implement intelligent retry with increasing wait times.

Strategy 3: Efficient pagination

Use pagination for searches returning many results. For large-scale bulk processing, see our guide on batch processing with the BCE API.

Strategy 4: Controlled parallel requests

Send multiple requests in parallel while respecting the limits.

Conclusion

By combining caching, intelligent retry, pagination and concurrency control, you maximize the performance of your integration while respecting API limits. Also make sure to secure your API keys properly.

Frequently asked questions

What is rate limiting in the BCE/KBO API and how do you avoid it ?

Rate limiting restricts the number of requests per minute and per day based on your plan (10 req/min and 100 req/day on free, up to 300 req/min and 50,000 req/day on Pro). To avoid hitting limits, cache company records with a 24-hour TTL, implement retry with exponential backoff on 429 errors and use controlled concurrency for batch processing.

What cache duration do you recommend for BCE/KBO data ?

For company records (address, status, directors), a 24-hour TTL is suitable since data is updated daily by the BCE. For very stable data such as NACE labels or legal forms, a 7-day TTL is reasonable. For active or inactive status checks in a KYC context, prefer a TTL of 1 to 4 hours to balance freshness and quota usage.

How do you implement an efficient retry on 429 errors from the BCE API ?

Read the Retry-After header in the 429 response to know the imposed wait time in seconds. Then implement exponential backoff: wait Retry-After times 2 to the power of the attempt number seconds between each try, with a maximum of 3 retries. Add a random jitter of 10 to 30 percent to prevent all your clients from retrying simultaneously.

How do you make parallel requests to the BCE API without exceeding quotas ?

Use a concurrency-limited queue: send for example 5 requests in parallel, wait for the batch to complete, then move to the next one. Continuously monitor the X-RateLimit-Remaining header between batches to dynamically adjust concurrency. This approach allows efficiently processing thousands of companies while staying within plan limits.