Skip to content

Keep your vehicle database current

Load the register once, then process only what changed. We compare every new version of RDW’s open data with the previous one and deliver the differences per registration and per field. No more running and diffing full imports yourself.

Mutations

To keep up: only what changed between two versions of the open data, per registration and per field, with the old and the new value.

New
A few times a day, after each new version of a dataset
Format
JSON from the API, or a mutation file in JSONL or CSV
Kept for
90 days
See the mutations

Snapshot

To start: the whole register at one moment, as files, one per dataset.

New
Every week
Format
JSONL and CSV
Keeping up
Every snapshot has a cursor in the mutation feed
See the snapshots

The mutation feed, mutation files and snapshots are part of these plans: Mutation feed · Vehicle API and mutation feed. See the plans and prices

The detected changes, in order

Each time RDW publishes a new version of a dataset, we compare it with the previous version we processed and list the differences: per registration and per field, with the old and the new value. You apply those differences to your own database.

When you see a change

  1. RDW publishes

    RDW decides when a dataset gets a new version, usually daily. Every change carries that moment in source_published_at.

  2. We check

    Several times a day we look for a new version. When there is one, we compare it with the previous one and turn the differences into a batch. observed_at is when we picked the batch up.

  3. You read the batch

    A batch is in the feed as soon as it has been processed completely. Because each dataset has its own moment, batches arrive a few times a day.

  4. What the feed is not

    It is not a log of events. You get the difference between two successive versions: when a value changes more than once in between, you see only the result. RDW publishes no time per change, so effective_at is always null.

Continuously, from the API

GET /api/v1/mutations

Read the feed page by page and carry on with the cursor from your last response. Follow everything, or filter by registration, dataset or type of change.

Per day, as a file

POST /api/v1/mutation-files

Request a mutation file: one day’s changes, or the changes between two cursors, as one JSONL or CSV file, with the same records as the feed. A mutation file stays available for 7 days and counts against the limit of your plan.

What you can count on

Only complete batches
A batch appears only when all of its changes are available. You never read half an update. GET /api/v1/mutations/batches lists them per dataset and day.
Positions that never change
New batches always get higher positions. Carry on with the cursor from your last response and you skip nothing, even when a batch arrives while you read.
Delivered at least once
After a failure you may get a change again. Deduplicate on id and set the field to the new value, and it makes no difference.
90 days to catch up
If your cursor is older, start again from a snapshot.
Starting without a snapshot
GET /api/v1/mutations/checkpoint gives a cursor at the head of the feed, with the same filters. Read on from there and you get only the changes that enter the feed after it.

Start with the whole register

A snapshot is the whole register as files, as it stood in RDW’s open data at that moment. Load it once and you have the starting state. Each snapshot belongs to a position in the feed, so you carry on with the mutations without a gap. A mutation file is something else: it holds only the changes of one day or between two cursors.

  • One file per dataset, in JSONL and CSV.
  • The same field names, types and units as the feed.
  • A new snapshot every week; the last two stay available.
  • A SHA-256 next to each file, to check your download.

From snapshot to a current copy

  1. Download the latest snapshot

    One file per dataset, in the format you want. The SHA-256 next to each file tells you the download is intact.

  2. Read the feed from the snapshot’s cursor

    Every change after the snapshot comes from GET /api/v1/mutations?after=….

  3. Store the new cursor after every page

    Even when the page is empty. Come back later and carry on where you left off.