{ "lookup" :
Using Dutch company data from outside the Netherlands
Short answer
Dutch trade register data is public and readable from anywhere. You do not need a Dutch entity, a Dutch bank account or eHerkenning to query it: an API key is enough. What you do need to get right is the data model, because Dutch addresses, names and identifiers do not map cleanly onto forms designed for other countries, and for cross border invoicing the field that matters is the VIES validated VAT number, not the KVK number.
# Works from any country
curl ".../v1/lookup/68750110?enrich=true" \
-H "Authorization: Bearer KEY"
{
"statutoryName": "Acme B.V.",
"address": {
"postalCode": "1016 GB",
"country": "NL"
}
}
What you do not need
Teams outside the Netherlands routinely assume that reading Dutch company data requires local presence. It does not. The practical checklist of things you can stop worrying about:
- eHerkenning. A Dutch business identity scheme for logging into government services. It exists so a company can file its own changes. Reading public data has nothing to do with it.
- DigiD. The citizen login. Same story, and it is not available to non residents anyway.
- A Dutch bank account or entity. Not required to hold an API key or to pay for one.
- A data licence. Core trade register data is public. Attribution and reuse conditions apply to bulk redistribution, not to looking a company up in your own product.
The operational side of getting started from abroad, including keys, billing and a first request, is covered in how to look up Dutch company data from outside the Netherlands. This page is about the shape of the data once you have it.
The data model, and where it fights your schema
| Field | What foreign schemas get wrong |
|---|---|
kvkNumber | eight digits, leading zeros are real. An integer column destroys them. |
statutoryName | absent for sole traders and partnerships. Fall back to name. |
tradingNames | an array, not a string. A company can trade under several names. |
address.houseNumber and houseNumberAddition | two fields, not one. 12 and A are separate. |
address.postalCode | four digits, a space, two letters: 1016 GB. Not numeric, and the space is conventional. |
legalForm | a code, not free text. Branch on it. |
vat | only present for BV and NV forms, and only after a VIES check. |
totalBranches | enrich only. Missing is not the same as zero. |
The postal code is the one that breaks silently. A validation regex written for five digit German or French codes rejects every Dutch address, and a normaliser that strips non alphanumeric characters turns 1016 GB into 1016GB, which is still valid but will not match a stored value that kept the space. Pick one canonical form and normalise on write.
The house number addition is the one that breaks expensively, because a parcel goes to the wrong door and nobody finds out until a customer complains.
Cross border invoicing: the field that actually matters
If you are selling into the Netherlands from another EU member state, the commercial question is whether you charge your own VAT or apply the reverse charge. That turns on the customer having a valid VAT identification number, confirmed against VIES. It does not turn on the KVK number at all.
curl "https://api.kvkbase.nl/v1/validate/vat/NL068750110B01" \
-H "Authorization: Bearer YOUR_API_KEY"Two things to build in from the start. Validate at invoice time, not only at signup, because what you are relying on is the status on the invoice date. And store the outcome with its timestamp, since that stored evidence is what you show when the position is questioned later.
If the customer gives you a KVK number rather than a VAT number, the lookup will try to derive one for a BV or NV and check it, but the derivation is a heuristic and fails on fiscal unities. Treat a missing or invalid result as “ask the customer”, never as “not VAT registered”.
A note on names and matching
Dutch statutory names carry a legal form suffix, and the punctuation of B.V. is inconsistent across sources. Diacritics appear in the register and disappear in user input. Names beginning with van, de and den are sorted and typed in several orders. Any exact string match between a Dutch register name and something a foreign system holds will fail more often than it succeeds.
Match on kvkNumber wherever you can. Where you cannot, normalise aggressively, accept a shortlist rather than a single answer, and show the city and legal form next to each candidate so a person can pick the right one. That is cheaper than the reconciliation work that follows a wrong automatic match.
Finally, plan for the calls you will not make. The free tier is fifty lookups a month, which is enough to build and test against real registrations but not enough to enrich a customer base. Cache what you retrieve, refresh on a schedule rather than on every page load, and use the cheap /v1/verify/{kvkNumber} call for input validation so full lookups are spent only where you actually consume the profile.
Frequently asked
Do I need eHerkenning to read the register?
Do I need a Dutch company or bank account?
Is a KVK number enough to invoice without VAT?
Can I store Dutch company data under GDPR?
Updated:
One call gives you the whole company
KVK data, the derived VAT number and a live VIES check, in a single request. The free plan covers 50 lookups a month and needs no card.
- 50
- free lookups a month
- 1
- request instead of three
- 0
- cards, contracts or sales calls