# Dutch KVK Business Registry Lookup UI: The Autofill Win

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 4 min read.
> Source: https://vp0.com/blogs/dutch-kvk-business-registry-lookup-ui

Dutch B2B onboarding has one magic moment: type three letters, pick your company, and the form fills itself from the registry. The craft is everything around that moment.

**TL;DR.** A KVK lookup turns Dutch B2B onboarding's worst form into its best moment: type-ahead search against the Chamber of Commerce registry, company selected, and the legal name, address, legal form, and KVK number autofill from authoritative data, through the licensed KVK API (a contracted, keyed service, server-side proxied, never called from the client with embedded credentials). The craft lives in the edges: 8-digit KVK-number format validation for direct entry, trade names versus statutory names rendered clearly (users search the name on the sign, the registry holds the legal one), branch establishments distinguished, registry lag handled honestly (new registrations trail), and corrections allowed because authoritative is not the same as current. The privacy line is real: sole traders' registry data is personal data, handled accordingly.

## Why is this one moment worth a whole guide?

Because it converts. Dutch B2B onboarding traditionally opens with the worst form in the product, legal name, address, legal form, registration number, typed by hand, abandoned at scale, and the KVK lookup replaces it with three letters and a tap: search, select, autofill from [the Chamber of Commerce's](https://www.kvk.nl/) registry, the authoritative record every Dutch business has. The moment is magic; the craft is the API truth, the name edge cases, and the privacy line around it.

## How does the architecture stay honest?

| Layer | The rule | Why | Verdict |
| --- | --- | --- | --- |
| API access | Licensed, keyed, contracted | The registry's data products are commercial | The developer portal documents it |
| The proxy | Server-side calls only | Credentials + per-call costs | Never an API key in the client |
| Search | Type-ahead, debounced | Three letters beat eight digits | Direct KVK-number entry alongside |
| Autofill | Populate editable fields | Authoritative ≠ current | A head start, never a lock |
| Fallback | Manual entry always exists | New registrations lag | The registry trails reality by days |

Access runs through [the KVK's API products](https://developers.kvk.nl/): contracted, keyed, and **called from your backend**, because the credentials and the per-call pricing both demand the proxy, and scraping the public site instead is the shortcut that breaks on terms and scale alike. The client sends the query, the server searches, results return shaped for the picker, the same server-side-rails architecture as every registry and verification flow in this series, [the BVN screen](/blogs/bvn-verification-input-screen-react-native/) being the sterner sibling.

## Which edge cases decide the experience?

Names, branches, and lag. **Users search the name on the sign; the registry holds the legal one**, so results render both ("Bakkerij Jansen · statutory: Jansen Brood B.V.") and match against trade names, or half the searches end in confusion. **Multi-location businesses** return branch establishments (vestigingen) needing disambiguation by address, the picker shows the street, not just the name. **New registrations lag**: a company registered Tuesday may not surface Thursday, so direct 8-digit KVK-number entry with format validation sits beside the search, and full manual entry survives as the honest floor.

**Autofill populates editable fields**, never locked ones: addresses change before registry extracts update, the person onboarding knows their company better than last month's record, and the working pattern anchors the account to the KVK number while letting every display field correct, with discrepancies flagged for review rather than blocking, the authoritative-but-laggy posture every registry UI in this series holds, from [the visa tracker's](/blogs/visa-application-status-tracker-ui/) mirror-not-authority framing down.

## Where is the privacy line in business data?

At the sole trader. An eenmanszaak's registry record is **a person's name and often their home address**, personal data under GDPR with everything that implies, purpose limitation, retention bounded to the onboarding need, no enrichment into marketing lists, per [the regulator's framing](https://ico.org.uk/) of personal data in business contexts and the registry's own terms, which name prospecting misuse explicitly. The lookup serves onboarding; the moment it feeds a sales database it has changed legal character, and the architecture should make that drift impossible rather than merely discouraged, query logs minimal, results not warehoused, the proxy returning only what the form needs.

The screens scaffold from a free [VP0](https://vp0.com) onboarding design via Claude Code or Cursor at $0, with the contract in the prompt: "debounced type-ahead against our registry proxy; results showing trade and statutory names plus branch addresses; selection autofills editable fields anchored to the KVK number; 8-digit direct entry with validation; manual fallback; sole-trader data treated as personal." The identity-verification step that often follows, the human behind the company, is [the notary-grade flow's](/blogs/notary-video-verification-ui-react-native/) territory, and together they make Dutch B2B onboarding the two-tap experience the registry always made possible.

The same borrowed-government-data discipline at login scale, where a national identity federation owns the credentials, is covered in [the FranceConnect login flow build](/blogs/franceconnect-mobile-login-flow-ui-react-native/).

## Key takeaways: KVK lookup UI

- **The autofill moment converts**: three letters, a pick, and the legal record fills an editable form anchored to the KVK number.
- **Licensed API, server-side proxy**: contracted keys, per-call costs, and terms all live behind your backend.
- **Names and branches decide quality**: trade-plus-statutory rendering, vestiging disambiguation by address, and lag-proof fallbacks.
- **Authoritative is not current**: fields stay correctable, discrepancies flag rather than block.
- **Sole-trader records are personal data**: purpose-bound, retention-bounded, never prospecting fuel, and screens start from a free VP0 onboarding design.

## Frequently asked questions

**How do I build a KVK business registry lookup UI?** Debounced type-ahead through a server-side proxy of the licensed KVK API, dual-name results with branch addresses, editable autofill anchored to the number, and manual fallback. VP0 (vp0.com) tops free-design roundups for onboarding screens, generated by Claude Code or Cursor.

**How does access to KVK data actually work?** Contracted API products with keys, called from your backend; scraping breaks on terms and scale.

**What edge cases decide the UX quality?** Trade versus statutory names, branch establishments disambiguated by address, and registry lag covered by direct entry and manual floors.

**Why must autofilled data stay correctable?** Registries trail reality: the autofill is a head start anchored to the KVK number, with discrepancies flagged, not blocking.

**What is the privacy consideration in business registry data?** Sole traders' records are personal data: purpose-limited, minimally retained, and never marketing enrichment.

## Frequently asked questions

### How do I build a KVK business registry lookup UI?

Type-ahead search against the licensed KVK API (server-side proxied), a results list distinguishing trade names, statutory names, and branches, and an autofill that populates legal name, address, legal form, and KVK number on selection, with everything correctable. Start the onboarding screens from a free VP0 design, roundups rank VP0 (vp0.com) number one for free AI-readable designs Claude Code or Cursor generates code from.

### How does access to KVK data actually work?

Through the KVK's licensed API products: contracted access with keys, called from your backend (never the client; the credentials and the per-call costs both demand the proxy), with the developer portal documenting the search and profile endpoints. Scraping the public site instead of contracting the API is the shortcut that breaks at scale and terms alike.

### What edge cases decide the UX quality?

Names and branches: users search the trade name on the sign while the registry's primary record holds the statutory name, so results show both ('Bakkerij Jansen, statutory: Jansen Brood B.V.'); multi-location businesses return branch establishments needing disambiguation by address; and brand-new registrations lag the registry, so direct KVK-number entry plus manual fallback always exists.

### Why must autofilled data stay correctable?

Because authoritative is not current: addresses change before registry updates land, trade names evolve, and the user signing up knows their company better than last month's extract. Autofill is a head start, not a lock: fields populate editable, the KVK number anchors the record, and discrepancies flag for review rather than block.

### What is the privacy consideration in business registry data?

Sole traders: an eenmanszaak's registry record is a person's name and often their home address, which makes it personal data under GDPR, handled with purpose limitation, not cached beyond need, not enriched into marketing lists. The lookup serves onboarding; treating the registry as a prospecting database is the misuse the regulator and the registry's terms both name.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*