Branches and head office in Dutch company data

One registration, many places

The Dutch register separates the business from the places it operates. Vestiging means establishment. The hoofdvestiging is the head office, and every other location is a nevenvestiging. All of them belong to one registration and therefore to one KVK number.

The eight versus twelve digit distinction is the fastest way to tell which number you are holding when a customer pastes something into a support ticket. If it is twelve digits, it is a location, and you cannot look a company up by it.

Two structures that look similar and are not:

• A company with four shops. One KVK number, four vestigingsnummers, one legal counterparty. Your contract and your invoice go to the company.
• A group with four operating companies under a holding. Four KVK numbers, four legal counterparties, and the group relationship is not a field the API returns. If you need the group, you need a source outside the register.

Fetching the data

The count comes with enrichment, the list comes from its own endpoint.

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

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

The useful pattern is to read totalBranches first and only call the branch endpoint when it is greater than one. Most Dutch registrations are single location, so you skip the second call for the large majority of companies and your quota lasts noticeably longer. If you are enriching a customer base in bulk, that alone can halve your call volume.

Do not build the reverse assumption into your code: totalBranches can be absent (no enrich) or zero (an entity registered without a place of business, which does happen with holdings). Handle both without throwing.

Where it matters in a product

• Checkout and delivery. Prefill the head office address, then offer the branch list if the count is above one. Getting this wrong sends a pallet to a registered office that is a bookkeeper’s front room.
• Territory assignment. A national chain legitimately belongs to several sales regions. Assigning on the head office postcode alone concentrates every large account in Amsterdam and Rotterdam.
• Site level operations. Field service, installations and inspections happen at a vestiging, not at a company.
• Deduplication. If you import customer records from several sources, the same company arrives as several rows with different addresses. Matching on address will split it. Matching on KVK number will merge it correctly.

If your product never touches a physical location, skip all of it. Storing branch data you do not read is a table you have to keep fresh for nothing.

The gotcha: the head office address is not always where post arrives

Two separate things get confused here. The address on a lookup is the head office visiting address. postalAddress, an enrich only field, is where the business receives mail, and for a meaningful share of registrations they differ. Small companies register at their accountant’s or a domicile provider’s address and take post somewhere else entirely.

If you print invoices or send paper anywhere, use postalAddress when it is present and fall back to address when it is not. If you are judging whether a company is real, be aware that a shared domicile address is common and legal, so an address with hundreds of registrations on it is a weak signal, not proof of anything.

One more detail worth encoding once: Dutch addresses split the house number from its addition. address carries houseNumber and houseNumberAddition separately, so 12 and A are two fields rather than 12A. Forms designed around a single free text street line lose the addition on the round trip, and a delivery to Keizersgracht 12 instead of Keizersgracht 12A is a different door. Model the two fields separately from the start.

If you already store addresses for other countries, resist the urge to squeeze the Dutch shape into an existing single line column and parse it back out later. Parsing Keizersgracht 12A hs correctly requires knowing Dutch conventions for additions and floor labels, and the register already did that work for you. Keep the fields it gives you and concatenate for display only.