You need to know if a Dutch-registered vehicle has an open recall, reliably and fast, without scraping RDW datasets yourself. By the end of this guide you’ll be able to query the Vehicle API RDW endpoint with a Dutch plate, read the open_recall flag in a standardized JSON envelope, handle errors and nulls, and ship this into dealer, marketplace, fleet, insurance or AI agent workflows.
What you get from the RDW Open Recall lookup
The RDW Open Recall lookup is a plate-based POST endpoint that normalizes Dutch “kenteken” input (with or without dashes) and returns RDW open data for that registration. The key field for this article is data.open_recall, a boolean indicating whether there is a known open recall for the vehicle in Dutch RDW data.
Because RDW does not publish VINs, data.vin is always null for this endpoint. You will still get useful attributes for matching and display (year, make, model, body, color, doors, seats, vehicle_type, engine details, mass_kg, APK expiry, and first registration date) alongside the open_recall flag.
This is not a vehicle history report. There is no title, accident, or ownership history. Recalls, complaints and NCAP ratings for US-market vehicles are also available via Vehicle API, but they are US-only and matched by make, model and year; they are not returned by this RDW plate endpoint.
Endpoint and authentication
Base URL: https://vehicles-api.com/api/v1
Endpoint: POST /plate/nl
- Header authentication: X-API-Key: YOUR_API_KEY (Authorization: Bearer YOUR_API_KEY also works)
- Content-Type: application/json
- Body: {"plate":"K875HJ"} (dashes are optional; K-875-HJ works)
The response is always a JSON envelope with status, source, and data on success, or status error with error.code and error.message on failure. Unknown plates return a 404 not_found. See the Documentation for plan-specific rate limits and quotas.
cURL: RDW Open Recall lookup by Dutch plate
The following is the official, copy-pasteable cURL example. It posts a Dutch plate to the RDW plate endpoint and returns the standardized envelope with the open_recall flag.
curl -X POST "https://vehicles-api.com/api/v1/plate/nl" -H "X-API-Key: YOUR_API_KEY" -H "Content-Type: application/json" -d '{"plate":"K875HJ"}'Python example: parse the open_recall field
import json
import requests
API_KEY = "YOUR_API_KEY"
URL = "https://vehicles-api.com/api/v1/plate/nl"
def rdw_open_recall(plate: str) -> dict:
"""
Look up a Dutch plate (with or without dashes) and return the parsed envelope.
"""
headers = {
"X-API-Key": API_KEY,
"Content-Type": "application/json",
}
payload = {"plate": plate}
resp = requests.post(URL, headers=headers, data=json.dumps(payload), timeout=10)
# Raise for non-2xx to make error handling explicit at the call site
if resp.status_code == 404:
# Example: unknown plate; Vehicle API uses envelope errors.
# We still try to decode the JSON to surface code/message.
try:
err = resp.json()
except ValueError:
err = {"status": "error", "error": {"code": "not_found", "message": "Plate not found"}}
raise RuntimeError(f"Lookup failed: {err}")
resp.raise_for_status()
envelope = resp.json()
if envelope.get("status") != "success":
raise RuntimeError(f"Unexpected status: {envelope}")
return envelope
if __name__ == "__main__":
# Dashes are optional: "K-875-HJ" would also work
envelope = rdw_open_recall("K875HJ")
data = envelope.get("data", {})
# Core flag for this guide
open_recall = data.get("open_recall")
# Useful context fields for display or indexing
plate = data.get("plate")
year = data.get("year")
make = data.get("make")
model = data.get("model")
apk_expires = data.get("apk_expires") # YYYY-MM-DD
vin = data.get("vin") # Always null for RDW
print(f"Plate {plate}: open_recall={open_recall}, {year} {make} {model}, APK expires {apk_expires}, VIN={vin}")Official JSON response
Below is the official JSON envelope example for this endpoint. Copying the structure exactly will help you build robust parsing and error handling.
{
"status": "success",
"source": "plate_nl",
"data": {
"plate": "K875HJ",
"vin": null,
"year": 2021,
"make": "TOYOTA",
"model": "AYGO",
"body": "hatchback",
"color": "GRIJS",
"doors": 4,
"seats": 4,
"vehicle_type": "Personenauto",
"engine": {
"cylinders": 3,
"displacement_cc": 998,
"fuel": "Benzine"
},
"mass_kg": 815,
"apk_expires": "2027-01-04",
"first_registration": "2021-01-04",
"open_recall": false
}
}Fields you will actually use
- status: "success" (string). Check this before consuming data.
- source: "plate_nl" (string). Helpful for logging and analytics when you aggregate responses from multiple endpoints.
- data.plate: "K875HJ" (string). Normalized plate. RDW accepts with or without dashes; Vehicle API returns a normalized form without dashes.
- data.vin: null. Always null for Dutch RDW plates; RDW never publishes VIN.
- data.year: 2021 (number). Model year as available in RDW open data.
- data.make: "TOYOTA" (string). Uppercase manufacturer label.
- data.model: "AYGO" (string). Uppercase model label.
- data.body: "hatchback" (string). Body style.
- data.color: "GRIJS" (string). Dutch color names may be uppercase and Dutch-language.
- data.doors: 4 (number). Door count.
- data.seats: 4 (number). Seating capacity.
- data.vehicle_type: "Personenauto" (string). Dutch vehicle type label.
- data.engine (object):
- cylinders: 3 (number)
- displacement_cc: 998 (number)
- fuel: "Benzine" (string, Dutch)
- data.mass_kg: 815 (number). Mass in kilograms.
- data.apk_expires: "2027-01-04" (string, YYYY-MM-DD). APK inspection expiry date.
- data.first_registration: "2021-01-04" (string, YYYY-MM-DD). First registration date.
- data.open_recall: false (boolean). RDW open recall status for the vehicle.
Nulls: Expect nulls where RDW does not publish something (vin is always null). Your integration should not assume every optional field is present for every record.
Caveats and coverage
- RDW data, Dutch plates: This endpoint provides Dutch RDW open data keyed by plate. VIN is never available from RDW; data.vin will be null.
- open_recall scope: data.open_recall is based on RDW open data. It is not a US NHTSA indicator and does not include US-only datasets.
- US-market datasets: Vehicle API also provides official US safety data (recall campaigns, owner complaints, NCAP crash ratings) matched by make + model + year for US-market vehicles. Those datasets are not returned by this RDW plate endpoint.
- VIN decoding: Vehicle API decodes VINs worldwide with fullest coverage for US-market vehicles. This RDW endpoint does not accept or return VINs.
- Not a history report: No title, accident, or ownership history is included anywhere in this endpoint’s response.
Response envelope, errors, rate limits, and caching
Envelope
Every successful response is wrapped as: status: "success", source: "plate_nl", data: { ...fields... }.
On failure, you will receive: status: "error" and error: { code, message }.
Error handling
- 404 not_found: Plate not found in RDW open data. For example: {"status":"error","error":{"code":"not_found","message":"Plate not found"}}.
- 401 unauthorized or 403 forbidden: Missing or invalid API key.
- 4xx validation: Ensure Content-Type is application/json and plate is a non-empty string.
- 5xx: Transient server issues. Implement retries with backoff; do not retry indefinitely.
Rate limits and monthly quota
Rate limits and quotas are enforced per plan. The Starter plan begins at $19/month, and every plan includes a 7-day free trial. For exact per-plan limits and headers, see the Documentation.
Caching recommendations
- Normalize input: Accept “K-875-HJ” and “K875HJ” from users; send normalized plate text in your request.
- Cache by plate: RDW open data is stable for most fields. Cache successful lookups by normalized plate to reduce latency and cost. Choose a TTL appropriate to your business tolerance for staleness, and refresh as needed.
- Cache misses carefully: Cache 404s briefly to avoid hammering the endpoint with nonexistent plates, but keep TTL short to allow for newly registered plates entering RDW open data.
- Treat nulls as stable: vin is consistently null; code paths should avoid assumptions that a VIN will appear later for the same plate.
Production build notes
- Plate normalization: Store and display the canonical plate returned in data.plate to avoid duplicate cache keys for dashed vs. non-dashed inputs.
- Localization: color and vehicle_type strings are Dutch (e.g., "GRIJS", "Personenauto"). If your UI targets non-Dutch speakers, map these to localized labels.
- Units and formats: mass_kg is kilograms; engine.displacement_cc is cubic centimeters; dates are YYYY-MM-DD (no timezone offset applied).
- Downstream joins: If you show additional safety data for US-market vehicles, that is a separate call matched by make + model + year. Do not expect the RDW plate endpoint to contain US datasets.
- Alerting: If you rely on open_recall for operational workflows (e.g., rental readiness), log both the boolean result and the lookup timestamp. Refresh on a schedule suitable for your compliance obligations.
Working alongside VIN decoding and US safety data
Vehicle API supports multiple data workflows behind one platform. Use the RDW plate endpoint for Netherlands registrations and, separately, decode VINs anywhere in the world (fullest for US-market vehicles). For official US recalls, owner complaints and NCAP ratings, query those datasets by make, model and year for US-market vehicles. Keep in mind that those US datasets are not part of this RDW endpoint and are US-only.
If you are orchestrating multi-step workflows or building agents and tools that need to combine plate and VIN logic, the MCP server at MCP exposes the same capabilities for agentic runtimes alongside the REST API at https://vehicles-api.com/api/v1.
Testing checklist
- Send a valid POST with application/json and X-API-Key: YOUR_API_KEY.
- Verify status == "success" and source == "plate_nl" before reading data.
- Confirm data.vin is null, and your downstream logic tolerates null VINs.
- Read data.open_recall as boolean; don’t cast strings.
- Validate date parsing for apk_expires and first_registration (YYYY-MM-DD).
- Surface 404 not_found clearly in your UI or logs.
- Cache by normalized data.plate; handle dashed and non-dashed inputs uniformly.
Troubleshooting
- Always null VIN: This is expected. RDW never publishes VINs for plate data. If you need a VIN, you cannot derive it from this endpoint.
- Mismatch on make/model casing: RDW strings are often uppercase. Normalize if your database expects Title Case.
- Open recall expectations: data.open_recall is from RDW open data (Netherlands). It does not reflect US recall status.
- 429 or plan errors: Respect your plan’s limit. Implement retry/backoff and consult the Documentation for specifics.
FAQ
Does the RDW endpoint return a VIN?
No. RDW never publishes a VIN for Dutch plates; data.vin is always null.
What does data.open_recall represent?
A boolean flag indicating whether there is an open recall recorded in Dutch RDW open data for the given registration. It is not derived from US NHTSA data.
Can I check US recalls for the same vehicle?
Yes, but that is a separate capability matched by make + model + year for US-market vehicles. It is not included in the RDW plate response and is US-only.
What happens if the plate is unknown?
Vehicle API returns a 404 not_found with an error envelope. Handle this by informing the user or queuing a recheck later; optionally cache the miss briefly.
How do I authenticate?
Send your key in the X-API-Key header. Authorization: Bearer YOUR_API_KEY is also accepted.
Start integrating the RDW Open Recall check with a 7-day free trial. The Starter plan is $19/month, and you can be live in minutes. Create an account at Register, explore the endpoint details in the Documentation, and, if you build agents, check out MCP for the same capabilities over an MCP server.
