Secure BCE/KBO API keys: best practices 2026

In brief

Your BCE/KBO API keys (public key + secret key pair) grant access to official Crossroads Bank for Enterprises data on your behalf. A leak exposes your quota, your data and your identity. Three non-negotiable rules: store keys in environment variables, never expose them on the client side, and rotate them every 90 days.

Why secure your API keys?

Your API keys provide access to BCE/KBO data on your behalf. If compromised, a third party could:

Consume your request quota

Access your company data

Impersonate you in logs

Fundamental rules

1. Never expose on the client side

The secret key (sk_live_...) should never appear in:

Client-side JavaScript code

Decompilable mobile applications

Public Git repositories

2. Use environment variables

Terminal

1
2
3

# .env.local (never committed)
API_PUBLIC_KEY=pk_live_your_key
API_SECRET_KEY=sk_live_your_secret

3. Regular key rotation

Change your keys every 90 days

Create the new key before deleting the old one

4. Limit permissions

Use different keys for each environment (dev, staging, prod)

Enable expiration alerts in your dashboard

In case of a leak

If your secret key is compromised:

Deactivate the key immediately in the dashboard

Create a new key pair

Update all your applications

Check usage logs for abuse

Conclusion

The security of your API keys is your responsibility. By following these best practices, you protect your data and that of your users.

Frequently asked questions

Why should a secret API key never be exposed on the client side in Belgium?

The secret key (sk_live_...) of a BCE/KBO API authenticates on your behalf against Company Belgium servers. If it is included in client-side JavaScript or a decompilable mobile app, anyone can extract it and use it to consume your quota, access your data or impersonate you in logs. It must always remain server-side, loaded from an environment variable.

What is the right way to store API keys in a Node.js or Python project?

In both cases, store your keys in a .env file that you add to .gitignore. In Node.js, use the dotenv package and access keys via process.env.API_PUBLIC_KEY. In Python, use python-dotenv and os.getenv(). Never hardcode keys in the source code. For production environments, prefer a secrets manager such as AWS Secrets Manager, HashiCorp Vault or Kubernetes secrets.

What to do if a BCE/KBO API key has been exposed in a public Git repository?

Act immediately in four steps: deactivate the compromised key in your Company Belgium dashboard, create a new key pair, update all applications that used the old key, then check usage logs for unauthorized access. Deleting the commit is not enough: treat the key as permanently compromised from the moment of exposure and revoke it.

How often should you renew the API keys of a BCE/KBO integration?

The recommended best practice is rotation every 90 days. Always create the new key before deleting the old one to avoid service interruption. Use different keys for each environment (development, staging, production) and for batch jobs, so you can revoke a specific access without affecting others. Also enable expiration alerts in the Company Belgium dashboard.