In many transportation and logistics companies, this is still standard practice: vehicle managers looking up license plate numbers one by one, keeping track of vehicle inspection dates in spreadsheets, and submitting exemption requests individually. This work can be largely automated, provided you understand that the RDW has not one, but two fundamentally different portals. One is open and free; the other is regulated and secure. These two portals correspond to two directions in any integration: retrieving data and submitting data. In this article, you’ll learn how to automate both directions within a fleet management platform and why that specific combination is what sets a platform apart.
What is RDW integration, and why is it becoming more urgent now?
The RDW (Road Traffic Authority) registers all Dutch vehicles and is responsible for, among other things, license plates, APK inspections, and type approvals. For any company with a fleet, the RDW is therefore an indispensable data source. Yet in practice, the exchange of that data is often still done manually. This takes time, leads to errors, and doesn’t scale well as a fleet grows.
Moreover, the urgency is increasing. Since January 1, 2026, the RDW has been operating under a revised accreditation system: a single Basic Accreditation, under which specific accreditations such as APK, export, or company inventory fall. Oversight is becoming more digital, and up-to-date, accurate records carry greater weight than before. Accreditation holders maintain their business records via Mijn RDW Zakelijk, and a specific accreditation automatically expires as soon as the Basic Accreditation is revoked. This does not affect every transportation company equally, but it does affect everyone with their own workshop, inspection activities, or company inventory. Those who automate these processes smartly now will have a head start later.
How does RDW integration work? Two directions: retrieval and submission
Every RDW integration consists of two directions, and that distinction determines the rest of your architecture.
- Inbound: from the RDW to your platform. You retrieve data to enrich your own system. This side is open, free, and fully API-driven.
- Outbound: from your platform to the RDW. You submit data or file reports. This side is authenticated, regulated, and often handled through an external provider.
So reading is simple, while writing is regulated. Because both sides impose very different requirements on technology, security, and management, we’ll address them separately, starting with the simplest.
Automating incoming data flows: the RDW Open Data API
The incoming side relies entirely on open data. The RDW makes large portions of its registries available so that other parties can reuse that data in their own applications. The source is the vehicle registration registry, also known as the Basic Vehicle Registry. This includes general vehicle information, fuel consumption and environmental data, and the history of registration and ownership.
Getting started is easy: for basic use, you don’t need an API key or license; the data is covered by an open license, and the datasets are updated daily. For each dataset, the data is available in common formats, including JSON, CSV, XML, and RDF. With higher volumes, you’ll encounter throttling: without an application token, stricter limits apply than with one. This is something to factor into your design right away.
The practical value for a fleet management platform lies in four applications:
- License Plate Enrichment: When adding a vehicle, your system automatically fills in the make, model, year, fuel type, and weight. No manual work, no typos.
- MOT monitoring: You retrieve the expiration date and inspection history and convert them into automatic reminders well before the deadline. An expired MOT means downtime and fines—exactly what you want to avoid.
- Recall monitoring: Manufacturers are required to notify the RDW of recalls, and that recall registry is available as open data. The link is based on make and model, not on the individual license plate number. Your platform can therefore proactively screen a fleet by make, model, and model year, after which the importer or dealer confirms the details for each vehicle.
- Environmental and zone data: Based on emission class and fuel type, you can perform compliance checks, for example, regarding zero-emission zones. Note the division of roles: the RDW provides the vehicle characteristics, while the zone boundaries and exemption rules come from municipalities and the central office.
There are also limitations on the open data side. Information on whether a vehicle is registered as stolen or missing is not provided via open data. The same applies to the WOK status: this was deliberately removed from the open vehicle data because its history was being used to suggest a damage history that did not always exist. In addition, vehicles only appear in the dataset once they have been registered in a person’s name, which can cause a delay in the case of imported vehicles. Taking these limitations into account early in the design phase helps prevent surprises during production.
Submitting data to the RDW: outbound data flows and the provider model
As soon as you send data in the other direction, the game changes completely. On the outgoing side, you do not work with an open API. Authentication, authorizations, and oversight apply here, and that is precisely where the complexity lies.
This typically takes place via a provider model. A provider handles data communication with the RDW and effectively serves as the gateway to the digital connection. An accredited company registers with such a provider by providing its business registration number. The data you submit through this channel is relevant for transportation companies with their own repair shops or inventory: think of vehicle registrations, inventory changes, odometer readings, and MOT deregistrations.
This is precisely where the updated accreditation system has the greatest impact. The requirements for digital record-keeping are becoming stricter, and the RDW can automatically verify submitted data. Data quality has thus become a compliance issue rather than an internal quality objective. Just how strict this verification is in practice is clearly illustrated by one everyday example.
Real-world example: Applying for an exemption for exceptional transport via Crosweb
Take the exemption for exceptional transport, for example. Vehicles that are longer, wider, taller, or heavier than permitted by law may only be driven on public roads with a permit from the RDW. You apply for this permit via the RDW application Crosweb, for which you need a customer number and a Crosweb certificate. This certificate is issued to the organization, is valid for two years, and may be installed on multiple workstations. It is sent by mail on a USB drive, with the installation PIN sent separately. The RDW couldn’t make it any clearer that this is not an open API.
Crosweb is a web application that requires certificate-based login, so the application process itself cannot be fully automated. The recurring nature of the process, however, lends itself perfectly to automation. An annual exemption is valid for one year and must be reapplied for afterward; it applies only to routes that appear in green on the Digital Road Map for Exemptions. A platform that monitors expiration dates, sends timely reminders, and prepares the application data for each vehicle in a ready-to-use format relieves vehicle managers of a recurring burden.
Linking RDW data to TMS, telematics, and route optimization
This completes the technical aspect of pickup and delivery. But RDW data is rarely an end in itself. Its value is realized when you connect that data to the systems where the real work happens.
In a TMS (Transport Management System) or Freight Management System, weight, axle configuration, and emission class determine whether a trip is even permitted on a specific route and within a specific zone. In telematics and track-and-trace applications, RDW data supplements the vehicle context that the onboard computer itself does not provide. In route optimization, vehicle characteristics are a strict prerequisite rather than a mere preference, and in yard and parking management, you link a scanned license plate directly to verified vehicle data.
That interplay is the field in which we work every day. NetRom builds software for the transportation and logisticssector , ranging from TMS and WMS to telematics and parking management.
Five design choices for an RDW integration that holds up in production
Such a backend layer is only reliable if it’s built properly. The difference between a prototype and a production-ready RDW integration lies in five design choices:
- Caching and rate limiting: With large fleets, you want to remain fast and reliable without overloading the open data source. Vehicle data doesn’t change every second, but your application must respond in milliseconds.
- Robust error handling: What happens if the source is temporarily unavailable? Structured error handling and monitoring determine whether your integration will remain operational even on a bad day.
- Certificate and authorization management: The outbound side requires secure handling of certificates and authorizations: storage in a vault, rotation, and a complete audit trail. At its core, this is a cybersecurity issue.
- Data quality and synchronization: Open data is updated daily, so it’s near-real-time rather than real-time.
- Scalability: A single integration for a SaaS platform with hundreds of customers is a different challenge than an integration for a single internal fleet. The architecture must fit the use case.
Caching, error handling, certificate management, and scalability aren’t something you can address after the fact; they determine how you design the integration from the outset. For a growing fleet management platform, a modular architecture helps keep external integrations manageable and prevents changes from rippling through the entire platform. This is familiar territory for us: integrations with third-party systems are a standard part of the platforms we build.
Looking to have an RDW integration built for your fleet management platform?
Moreover, a reliable integration doesn’t stand alone. Choices regarding architecture, security, data quality, and management also determine whether the entire platform remains future-proof. That’s why you should also read about the pitfalls to avoid when developing a fleet management platform.
Do you want to automatically retrieve RDW data, support vehicle processes more intelligently, or reliably integrate an existing RDW connection into your fleet management platform? NetRom helps design, develop, and integrate scalable software for transportation and logistics. From API integration and data processing to security and connectivity with existing systems.
Discuss your integration needs with our specialists. Contact us for a no-obligation consultation about the technical possibilities for your platform.