What is a vestigingsnummer?

Two numbers, two questions

Dutch company data uses two identifiers that look similar and answer completely different questions. Getting them mixed up is the single most common modelling error we see in integrations built from outside the Netherlands.

The word vestiging means establishment or place of business. A hoofdvestiging is the head office, a nevenvestiging is any other location. The register does not use the word “branch” in the legal sense that some countries do, where a branch is a separately registered entity of a foreign parent. A Dutch nevenvestiging is not a separate legal entity, has no legal personality of its own, and cannot contract in its own name.

If you already work with French data, the analogy is close: SIREN is to SIRET as the KVK number is to the vestigingsnummer. If you work with UK or German data, there is no direct equivalent, which is exactly why teams from those markets tend to flatten Dutch companies to one address and lose data.

When you actually need it

Most integrations never need a vestigingsnummer. You need it when your product cares about a specific location rather than the legal counterparty:

• Delivery and logistics. A wholesaler ships to a depot, not to the registered office. Different vestigingsnummers, same KVK number.
• Field service and territory assignment. Sales territories are drawn on locations, so a single company can legitimately belong to several reps.
• Employee counts per site. The enriched employees figures on a lookup are for the registration. Per site counts live at establishment level.
• Reconciling against Dutch supplier data. Some Dutch systems, notably in e-invoicing and public sector procurement, identify a counterparty by establishment rather than by company.

If none of those apply, key on the KVK number and move on. Fetching branch data you never read costs you quota and adds a table you have to keep fresh.

Getting them

The branch list hangs off the company:

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

If you only want to know whether the question is worth asking, the enriched lookup carries a totalBranches count:

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

Reading totalBranches first and only calling /branches when it is greater than one is a cheap optimisation. In practice the large majority of Dutch registrations are single location, so you skip the second call most of the time.

The gotcha: a vestigingsnummer is not stable across a move

Teams assume the vestigingsnummer behaves like the KVK number: assigned once, valid forever. It does not. It identifies an establishment, and an establishment is tied to a place. A company that closes a location and opens a new one gets a new vestigingsnummer, even when nothing else about the business changed. The old one stops appearing in the branch list.

That matters if you have foreign key constraints pointing at it. Do not make the vestigingsnummer the primary key of your locations table and do not put a NOT NULL foreign key on it from your orders table, or a routine relocation will orphan history you needed to keep. Store it as an attribute on your own location record, keep the KVK number as the join key back to the company, and treat a vestigingsnummer disappearing from the branch list as “this site closed” rather than “this data is corrupt”.

The related habit worth adopting: snapshot the branch list with a fetched timestamp rather than overwriting it. When a customer asks why an invoice from March went to an address that no longer exists, you want to be able to answer.

If you are only starting to model Dutch data, a reasonable first version has no locations table at all: one company row keyed on the KVK number, with the head office address on it. Add establishments when a real requirement appears, because retrofitting a locations table is straightforward while unpicking a schema that keyed orders on a vestigingsnummer is not.