How to check if a Dutch company is still active

The Dutch vocabulary, because the words are not interchangeable

Four Dutch terms get flattened to “closed” in English, and they mean different things for your risk model.

The one that trips up foreign teams is the middle block. A bankrupt Dutch company is still in the register and can still return isActive: true, because the registration is not closed until the estate is settled. If your check is if (isActive) proceed, you will happily extend credit to a company in administration.

Check both fields, always:

curl "https://api.kvkbase.nl/v1/lookup/68750110" \
  -H "Authorization: Bearer YOUR_API_KEY"

isActive is a boolean. insolvency carries the recorded insolvency state and is absent or empty when there is none. Neither field requires enrich=true, which makes this the cheapest useful check you can run.

A decision table that survives contact with reality

The third row is the interesting one. A registration going inactive is not automatically bad news. Sole traders convert to a BV and the old registration closes. Groups merge subsidiaries into the parent. A company relocates its registration. In all of those the counterparty still exists, often under a new KVK number you do not have yet.

Auto disabling accounts on isActive: false produces angry customers who did nothing wrong. Route it to a human, or at minimum surface it as a warning rather than an enforcement.

Why the 24 hour cache matters here specifically

Company data from this API is cached for 24 hours for active companies. On most pages that is a footnote. On this one it is the whole risk.

The chain of delays is longer than the cache alone:

1. The event happens, for example a court declares bankruptcy.
2. The publication is processed and the register is updated. This is not instant.
3. Our cache may serve a copy taken before that update, for up to 24 hours.

So the honest statement is: a true answer means “no closure or insolvency had been recorded as of some point in the last day”. That is a perfectly good input for onboarding, for a monthly portfolio sweep, for deciding whether to keep sending a newsletter. It is a weak input for releasing goods worth more than you can afford to lose, and you should say so internally rather than letting a green tick imply more than it means.

Practically: record the timestamp of the check next to the result. When something goes wrong, the question will be “what did we know and when”, and a boolean without a timestamp cannot answer it.

Monitoring rather than checking

A one off check at signup ages out immediately. If the counterparty relationship is ongoing, poll instead. Batch lookups make this affordable:

curl -X POST "https://api.kvkbase.nl/v1/lookup/batch" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"kvkNumbers":["68750110","12345678"]}'

Run it weekly over your customer base, diff isActive and insolvency against the stored values, and alert only on a change. That turns thousands of records into a handful of items a person actually reads. The scheduling, quota and alerting details are worked through in KVK company status monitoring.

One last habit that pays for itself: when you store the result, store the whole status triple rather than a single derived boolean. Keeping isActive, the insolvency value and the time of the check lets you answer later questions without re-querying, and it lets you distinguish a company you blocked because it was bankrupt from one you blocked because its registration closed. A single is_ok column throws that away, and you will want it back the first time a customer disputes a decision.