Custom KIK integration software for property professionals
Appfront builds software that makes your KIK Inzage integration with the Kadaster (the Dutch Land Registry) do what you expect of it: look up a parcel or a person, request the right product from the Basisregistratie Kadaster (the Land Registry's key register), store the response in a structured way against the file and attach the source documents. Every request is tied to a user, a timestamp and a reason. So nobody downloads loose extracts, renames them and puts them in the wrong folder any more.
What is KIK integration software for land registry data?
KIK integration software is the layer between your own system and the Kadaster's KIK Inzage API. The software searches by cadastral designation, address or person, requests the product you need from the Basisregistratie Kadaster, stores the response both as a document and as separate fields, and links it to the file it was requested for. Authorisation runs through the login method the Kadaster prescribes.
Without that layer, everything is done by hand. An employee logs in, requests ownership information, downloads the PDF and retypes the parcel number into the file. For a sale involving three parcels, that happens three times, and the fourth request gets forgotten. By the end of the month, it is no longer possible to trace which request belonged to which case and who bears the cost.
We build custom software because your workflow determines when which product is needed. A notary's office works from a deed file with a completion date, a municipality from a case number and a valuer from an assignment. The integration has to fit your file system, your roles and your cost recharging. A generic package does not know your file structure and writes requests away outside your own software.
Searching and requesting
Search by cadastral designation, address or person and then request exactly the product you need, without the employee having to work outside the file.
Recording against the file
The response arrives as a document and as structured fields, linked to file, user and timestamp, so a later request can be set alongside the previous one.
Accountability and recharging
Every request gets a line with reason, file and cost centre, so you can show afterwards who requested what and why it was necessary.
How we build your KIK integration software for land registry data
We start with the requests your office made last month and the files they belonged to.
We go through which products you request, at which step in the file that happens, who is allowed to do it and what currently happens to the response once it has arrived.
We arrange the technical connection to the API, set up the authorisation method together with you and configure your file types, roles, cost centres and product choices in the software.
Requesting from within the file, automatically storing responses, retrieving source documents, alerts when a request fails and a weekly overview of everything your office retrieved in that period.
We link the software to your file system, DMS and invoicing, test with real cases and take over maintenance, including updates when a new version of the API is released.
What KIK integration software for land registry data actually does
The components below appear in almost every KIK integration. Which ones you need depends on the products you request and the way your files are set up.
Searching by multiple criteria
Search by cadastral designation, address, postcode or person, with a results list from which the employee picks the right object before anything is requested.
Products from the BRK
Request targeted ownership, mortgage and cadastral information, so you never request a heavier product than this step in the file requires.
Retrieving source documents
Request deeds and other documents from the public register and attach them straight to the case file, with consistent naming and a fixed document type.
Logging per request
Every request records the user, time, case file and reason, so you can later account for why a particular item of personal data or parcel was consulted.
Permissions per role
Who may request, who may only view and who may act on behalf of someone else, set up per role and per branch rather than per employee.
Cost allocation and overview
Requests grouped by case file, cost centre and period, ready to pass on to your invoicing or accounting.
Who we build KIK integration software for cadastral data for
The software is designed for organisations that need cadastral information every day and where that information has to end up in a case file.
Notary firms
Working from a deed file with a completion date, where searches and source documents have to be in at the right moment. The integration with the deed file is the core here.
Estate agents and valuers
Need property details quickly for each assignment, often in bulk for a portfolio. Searching by address and recording the result against the assignment matter most here.
Municipalities and housing associations
Work from case numbers and need to account for who consulted which parcel. Logging and role-based permissions are central here.
Lenders and property managers
Check ownership and security interests when an application or change comes in. Requesting automatically at a fixed process step avoids manual work and forgotten checks here.
Technology and integrations
This page is about an integration with the Kadaster's KIK Inzage API and the software around it. For other Kadaster data, see our page on the Kadaster integration, for parcels our page on the BRK integration, and for notary offices our page on apps for notaries. You can read about our approach on custom software development.
Why Appfront for your KIK integration software for cadastral data?
An integration is only as good as the agreements around it. That is what we build on: fixed moments for requesting, fixed storage and a trail you can follow afterwards.
A request without a case file does not exist
We make every request start from a case file. That prevents loose PDF files in personal folders and turns accountability and cost allocation afterwards into a matter of filtering.
The Kadaster changes, your process stays
Authorisation methods and product versions change. We keep that side of the integration separate from your workflow, so a change to the API does not mean rebuilding your own software.
You keep the data and the code
The data you request is stored in your own environment and you receive the source code. You are not tied to a single supplier to add a product or case type.
Security and privacy for KIK integration software for cadastral data
The software contains cadastral data and personal data of rightholders, plus the reason why someone requested them. We set up access per role: request, view or manage. Every request and every view is logged, including the case file and reason. We set retention periods per document type, so you do not keep data for longer than your own policy and the GDPR allow.
The software runs in a European data centre, with encrypted storage and daily backups. Integrations with the Kadaster, your case management system and your DMS use their own keys, which can be revoked per integration.
Frequently asked questions about KIK integration software for cadastral data
Questions offices ask before starting on their own KIK integration.
The software connects your own system to the Kadaster's KIK Inzage API. From within a case file, you search by parcel, address or person and request the product you need. The response comes back as a document and as fields, with the source documents attached, and is logged.
Yes. You enter into an agreement with the Kadaster yourself and hold a Mijn Kadaster subscription. Requests run under your own connection and are invoiced to you as well. We build the software that uses that connection and help set up the authorisation.
The Kadaster prescribes a login method with a high assurance level. In practice, that means working with certificates or OAuth, linked to your organisation's identification number. We set that up, store the keys separately from the application and make sure they can be replaced.
That is possible, provided it fits within the terms of your connection. We then build a queue that spreads requests over time, resubmits failed requests and reports back per batch which objects were and were not retrieved, so a long list doesn't stall halfway through.
That is the aim. If your case management system or DMS has an interface, we write documents and fields directly to it. If not, we work with an export or an intermediate layer. We agree in advance which field is leading, so you don't end up with two versions of the truth.
That happens fairly regularly, including new versions and changed login requirements. We keep the interface separate from your workflow and follow the announcements. During maintenance, we test a new version on a test environment first and only go live once your requests keep working unchanged.
Check that first. Many deed and case management packages already have some form of Kadaster lookup, and if it fits the way you work, that is enough. Custom software makes sense if you have several systems side by side, if requests need to be accounted for or recharged per case, or if your package doesn't know your process steps.
Do you want Kadaster data directly in your own case file?
Tell us which products you request, which system your case files are in and who currently makes the requests. We will show you what the request screen, the storage with the case file and the recharging overview look like, and how that fits within custom software development.