# RDW Inspection Defect Incidence - by Date & Class, Per Record (`nexgensignal/rdw-inspection-defect-incidence-records`) Actor

Netherlands RDW periodic motor-vehicle inspection defect incidence (a34c-vvps) as clean grouped records - inspection date x defect code x inspection class, with event\_count. The vehicle plate is never read. ~444,324 rows. CC0. $0.05 per record.

- **URL**: https://apify.com/nexgensignal/rdw-inspection-defect-incidence-records.md
- **Developed by:** [NexGen Signal](https://apify.com/nexgensignal) (community)
- **Categories:** Business, Developer tools, Other
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $33.50 / 1,000 inspection defect records

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## RDW Inspection Defect Incidence - by Date & Class, Per Record

The Netherlands Vehicle Authority's periodic-inspection **defect incidence** as clean, per-group counts -
**one record per (inspection date x defect code x inspection class)**, with `event_count` the number of times
that defect was recorded. The vehicle plate is never read, grouped or emitted.

### What one record represents

The source is **RDW** (the Netherlands Vehicle Authority) open-data resource `a34c-vvps` - *Geconstateerde
Gebreken* (established/detected defects) from periodic motor-vehicle inspections (APK). The raw table is one
row per defect found at an inspection, keyed on the vehicle plate. This Actor **groups** it server-side on
three dimensions - the inspection date (`meld_datum_door_keuringsinstantie`), the RDW defect code
(`gebrek_identificatie`) and the inspection-class description (`soort_erkenning_omschrijving`) - and emits
**one record per group** with `event_count`, the count of inspection rows in that group. The plate
(`kenteken`) is never selected.

### Coverage and volume

The raw defect table holds about **24.6 million** rows (24,632,204 live); grouped on the three dimensions it
yields about **444,324** records - the grain this Actor delivers. Both figures were measured live at build
time against the door.

**Sol's Wave-3 index stated only ">=2,500" grouped records from 24,628,766 rows; measured live at build time
the raw table is 24,632,204 rows and the grouped set is 444,324 records - the live figures are what this
listing quotes.**

The Actor pages the Socrata SODA API with a server-side `GROUP BY`, 20,000 groups at a time, and stops as soon
as your **Maximum records** cap is met.

### Licence and attribution

RDW open data on `opendata.rdw.nl` is released into the **public domain (CC0)** - free to use without
restriction. The full notice travels on every record:

> RDW (Netherlands Vehicle Authority) open data, resource a34c-vvps (Geconstateerde Gebreken). Public domain / CC0 - free to use without restriction, attribution to RDW appreciated. Grouped incidence counts only; the vehicle plate (kenteken) is never read, grouped or emitted.

Attribution to RDW is appreciated and stamped on every record.

### Person-data policy

This is a grouped incidence table, and the defining property is that **no vehicle plate is ever read**. The
plate (`kenteken`) is the only potentially identifying column in the source; it is never named in the query's
`SELECT`/`GROUP BY`, never read and never delivered. A per-record assertion rejects `kenteken` (and any
owner/holder field) if it somehow appeared - verified with a planted-plate test that injects a plate into a
source row and confirms the record is refused. The three group dimensions are a date, a defect code and an
inspection-class description - no personal data.

### Interpretation caveat

One record per (inspection date x defect code x inspection-class) group from the RDW periodic motor-vehicle inspection defect table: event\_count is the number of times that defect was recorded on that date under that inspection class (the only computed value). The vehicle plate (kenteken) is structurally excluded - never read, grouped or selected. gebrek\_identificatie is the RDW defect code; the RDW defect-code lookup table (gebreken) can join a coded description downstream.

Values are reproduced verbatim from the source; the Actor never rewrites a field. `event_count` is a count of
inspection rows for that date-code-class group - it is defect **incidence**, not a rate or a per-vehicle
measure. `gebrek_identificatie` is the RDW defect code; the separate RDW defect-code lookup table (`gebreken`)
can join a coded description downstream if you want human-readable defect labels.

### Data quality and freshness

`event_count` is delivered as a real number; the three dimensions are the source's verbatim strings. The
`record_id` composes the three group keys, so the dataset is safe to diff, deduplicate or upsert. Every run
re-reads the live resource, so the data is as fresh as RDW republishes, and each record's `observed_at` stamp
dates the snapshot. The run's `RUN_RECEIPT` records how many records were delivered and charged and confirms
`charge_equals_delivered`.

### Provenance and compliance

Every run reads `opendata.rdw.nl/robots.txt` at runtime; the gate result (URL, status, byte length, SHA-256 of
the policy, crawl-delay) is written to the run's `RUN_RECEIPT`. The `/resource/` API path is outside the
portal's disallowed `/browse` paths, and the Actor honours the published crawl-delay. The API is keyless. The
Actor never bypasses a block or fetches through a mirror.

### Inputs

- **Maximum records** (`maxRecords`) - hard cap on grouped incidence records delivered and billed.

### Output

Records land in the Actor's default dataset and export as JSON, CSV, Excel or via the Apify API. A tabular
**overview view** surfaces the inspection date, defect code, inspection class and `event_count`.

### Fields in detail

The record leads with the composite `record_id`, then `meld_datum_door_keuringsinstantie` (inspection date),
`gebrek_identificatie` (RDW defect code) and `soort_erkenning_omschrijving` (inspection-class description),
followed by `event_count` - the only computed value. The provenance block - source, source\_dataset, licence,
attribution, caveat, observed\_at - closes every record.

### Why the grouped grain

The raw defect table is 24.6 million plate-keyed rows - too large and too personal to ship directly. Grouping
to date x defect code x inspection class does two things at once: it removes the plate entirely (no vehicle is
identifiable in the output) and it turns the table into an analysis-ready incidence series. A repair shop or a
risk model does not want individual inspection records; it wants how often each defect shows up, when, and
under which inspection class - which is exactly what `event_count` gives, at 444,000 clean rows instead of 24.6
million.

### Typical uses

Repair and risk teams use this cell to benchmark inspection-failure patterns - which defect codes are most
common, how their incidence moves over time, and how it differs by inspection class - as a compact, plate-free
series they can chart or model. Because the grain is the date-code-class group, a group-by on the defect code
collapses the time series per defect, and a filter on the inspection class isolates a vehicle category. A
scheduled run keeps a downstream defect-trend table current as RDW republishes, and the composite key makes the
dataset safe to upsert. Join `gebrek_identificatie` to the RDW `gebreken` lookup for readable defect labels.

### Scaling and limits

Set **Maximum records** low to sample cheaply or high to pull the whole ~444,000-row grouped series. The Actor
pages the SODA API with a server-side aggregate and delivers incrementally, so memory stays flat and you are
billed only for what is delivered. Because RDW republishes the defect table continuously, re-running picks up
new inspections automatically, and each record's `observed_at` stamp dates the snapshot - schedule a run to
keep a downstream defect-incidence table current.

### Reading the dimensions

The three group dimensions each carry meaning you can pivot on. `meld_datum_door_keuringsinstantie` is the date
the inspection body reported the inspection, so a group-by on it (or a truncation to month) turns the series
into a time trend. `gebrek_identificatie` is the RDW defect code - a stable identifier that groups every
occurrence of the same fault, and the bridge to the `gebreken` lookup table for a readable label.
`soort_erkenning_omschrijving` is the inspection class (for example the APK class for light vehicles), which
separates the vehicle categories so a heavy-vehicle trend never mixes with a light-vehicle one. Because all
three are plain strings and the count is a real number, the record loads without transformation and pivots
cleanly on any one dimension or any pair.

### Sibling Actors

It sits beside the fleet's three RDW vehicle-registration cells (registration cohorts, type approval, fuel emission) and the fleet's US NHTSA vehicle-safety cell. It shares its grouped-count engineering - the runtime robots gate, the structural plate
guard, push-then-charge billing and verbatim-value discipline - with the fleet's other RDW cells, and stays
distinct from the fleet's US NHTSA vehicle-safety cell (Dutch periodic-inspection defects vs US recalls and
complaints).

# Actor input Schema

## `maxRecords` (type: `integer`):

Maximum records delivered and billed. You are billed only for records actually delivered. Raise it to pull the full set.

## Actor input object example

```json
{
  "maxRecords": 500
}
```

# Actor output Schema

## `results` (type: `string`):

The delivered RDW inspection defect incidence record.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "maxRecords": 500
};

// Run the Actor and wait for it to finish
const run = await client.actor("nexgensignal/rdw-inspection-defect-incidence-records").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "maxRecords": 500 }

# Run the Actor and wait for it to finish
run = client.actor("nexgensignal/rdw-inspection-defect-incidence-records").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "maxRecords": 500
}' |
apify call nexgensignal/rdw-inspection-defect-incidence-records --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,nexgensignal/rdw-inspection-defect-incidence-records"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/FPpFbbTQsPgNZyMuG/builds/UXCDsO2ChL2SLBZBY/openapi.json