NL Parking Rates & Live Availability Monitor avatar

NL Parking Rates & Live Availability Monitor

Pricing

from $3.00 / 1,000 parking-results

Go to Apify Store
NL Parking Rates & Live Availability Monitor

NL Parking Rates & Live Availability Monitor

Clean, structured parking data for the Netherlands: current tariffs and real-time free-space counts per facility, sourced from RDW's national Open Parkeerdata feed. Detects when a garage's live status changes between runs.

Pricing

from $3.00 / 1,000 parking-results

Rating

0.0

(0)

Developer

Dennis

Dennis

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

0

Monthly active users

7 hours ago

Last modified

Share

NL Parking Rates & Live Availability Monitor ๐Ÿ…ฟ๏ธ

Clean, structured parking data for the Netherlands: current tariffs and real-time free-space counts per facility, straight from RDW's national Open Parkeerdata feed (Nationaal Parkeer Register). Detects when a garage's live status changes between runs, so you can build alerts, not just dumps.

No login, no API key โ€” this is the same open, government-published feed used by NL parking apps and navigation systems.

Why this actor?

The raw source feed is genuinely painful to work with: every tariff rule is repeated once per weekday (a simple hourly rate becomes 7 near-identical records), timestamps are Unix epoch seconds, capacity is sometimes only available in a completely separate live-status endpoint, and addresses are buried several levels deep. This actor does that cleanup for you:

  • ๐Ÿงน Tariff simplification โ€” the 7x weekday-duplicated raw entries are collapsed into one rule per unique price structure, with a computed โ‚ฌ/hour rate and a free / metered / daily_cap classification
  • ๐ŸŸข Live availability, normalized โ€” free spaces, occupancy %, and a plain available / nearly_full / full / closed status, not raw booleans you have to interpret
  • ๐Ÿ”” Change detection โ€” remembers each facility's status from the previous run and flags status_changed when it flips (e.g. available โ†’ full), so scheduled monitoring runs give you alerts, not noise
  • ๐Ÿ“ Resolved address & coordinates โ€” pulled from the facility's actual entrance, not the operator's town-hall mailing address
  • ๐Ÿ›ก๏ธ Stale-data awareness โ€” expired tariff periods are dropped rather than reported as current, and staticDataLastUpdated tells you how fresh each record is

Only about 526 of the ~14,870 facilities in the feed publish live occupancy; the rest have tariffs only (mostly street parking and P+R zones). The actor tells you which is which per record (hasRealtimeData).

When should an AI agent use this?

  • "How much does it cost to park at parkeergarage Forum in Groningen right now, and are there free spaces?"
  • "Is there still availability in a parking garage in Rotterdam I can drive to now?"
  • "Alert me when a specific garage's status flips from available to full."
  • "Compare the hourly parking rate across garages in a city before I decide where to park."
  • "Which parking facilities in this feed actually report live occupancy, and which only have tariff info?"
  • "Find the facility ID for a garage by name so I can monitor it in future runs."

What data do you get?

{
"identifier": "9f89a6c7-df06-45ea-adf6-0b94088fcb57",
"name": "parkeergarage Forum",
"operatorName": "Groningen",
"address": { "street": "Schoolstraat", "houseNumber": "16", "zipcode": "9712JS", "city": "Groningen", "province": "" },
"location": { "lat": 53.219207, "lon": 6.57081 },
"usage": "Garage parkeren",
"capacity": 325,
"evLaadpuntenCapaciteit": 10,
"tariffs": [
{
"description": "Garagetarief (1,00 euro/18 min)",
"kind": "metered",
"days": ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
"validFrom": "00:00", "validUntil": "23:59",
"rates": [{ "chargeEuro": 1, "chargePeriodMinutes": 18, "pricePerHourEuro": 3.33, "durationFromMinutes": 0, "durationUntilMinutes": null }]
},
{
"description": "Garagetarief (24,00 euro/1440 min)",
"kind": "daily_cap",
"days": ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
"validFrom": "00:00", "validUntil": "23:59",
"rates": [{ "chargeEuro": 24, "chargePeriodMinutes": 1440, "pricePerHourEuro": 1, "durationFromMinutes": 0, "durationUntilMinutes": null }]
}
],
"hasRealtimeData": true,
"realtime": { "open": true, "full": false, "capacity": 325, "vacantSpaces": 67, "occupancyPercent": 79.4, "status": "available", "lastUpdated": "2026-07-09T14:17:44.000Z" },
"changeType": "unchanged",
"previousStatus": "available",
"sourceUrls": { "static": "https://npropendata.rdw.nl/...", "dynamic": "https://npropendata.rdw.nl/..." }
}

Use cases

  • Parking-finder apps & dashboards โ€” one clean call per facility gets you tariff and live availability together, ready to render
  • "Notify me when it's full" alerts โ€” schedule runs with detectChanges on and route status_changed records to Slack/e-mail via Apify integrations
  • Price comparison โ€” compare pricePerHourEuro across garages in a city before you drive there
  • AI agents & MCP tools โ€” flat, predictable JSON with a small, well-described input schema; a single call returns everything needed to answer "is there parking near X, and what does it cost right now?"
  • Facility discovery โ€” leave query/facilityIds empty to browse a sample of facilities with live data, then narrow down by name

Quick start

Zero-config: returns the first 25 facilities that publish live occupancy, no input needed.

Search by name:

{ "query": "Groningen", "maxResults": 50 }

Monitor specific garages and alert on status changes:

{
"facilityIds": ["9f89a6c7-df06-45ea-adf6-0b94088fcb57", "76825e73-4c8d-4a9c-9061-6284afcd865c"],
"detectChanges": true
}

Schedule this hourly: the first run establishes a baseline, every later run only marks status_changed when a garage actually flips between available/full/closed.

Only currently-available garages right now:

{ "query": "Rotterdam", "onlyAvailableNow": true, "maxResults": 100 }

Input reference

FieldDescription
facilityIdsExact RDW facility UUIDs to fetch (skips name search)
queryCase-insensitive name search, e.g. a city or garage name
onlyWithRealtimeDataOnly facilities with live occupancy (default true)
onlyAvailableNowOnly open, non-full facilities (default false)
maxResultsCap on facilities fetched/checked per run (default 25, max 2000)
detectChangesCompare against the previous run and flag status changes (default true)
trackOccupancyHistoryBuild up an occupancy time series per facility across scheduled runs (default false)
maxHistoryPointsHow many past measurements to keep per facility (default 30)

Note: maxResults bounds how many facilities are fetched, before filters like onlyAvailableNow are applied โ€” so the final output can be smaller than the cap. This keeps run cost predictable instead of crawling the full ~14,870-facility index looking for matches.

Pricing

Pay per event: regular facility records are billed at the base parking-result rate; a detected availability-change-alert (a facility's live status actually changed since the last run) is billed at a higher rate โ€” you pay more for genuine insight than for a plain snapshot. When trackOccupancyHistory is enabled, each facility that gets a new history point is additionally billed at the occupancy-history-point rate ($0.005) โ€” this only applies to facilities with real-time data.

Data source & reliability

  • Source: RDW's Open Parkeerdata (Nationaal Parkeer Register), the Dutch government's public parking-data standard (SPDP2.0) โ€” data.overheid.nl, CC-BY licensed
  • No authentication required; this actor respects the source's rate limiting with automatic backoff and retry
  • One broken facility lookup never fails the whole run โ€” errors are collected per facility in the run's key-value store (RUN_SUMMARY)
  • Facility metadata (name, operator, address) is business/government data โ€” no personal data is collected

FAQ

Why doesn't every facility have live availability? Only municipalities/operators that have installed occupancy sensors publish a dynamicDataUrl. About 526 of ~14,870 facilities currently do โ€” mostly larger garages in bigger cities. Facilities without it still return full tariff information.

Why is a facility's tariff list empty? Its published validity period has expired in the source data. Rather than show stale pricing, the actor drops it โ€” check staticDataLastUpdated for freshness.

How do I find a facility's ID? Run once with a query (e.g. a city name) and no facilityIds โ€” the returned identifier field is reusable in future runs.

Where is the change-detection history stored? A compact per-facility status snapshot lives in the actor's key-value store; each run compares against it and updates it.

What does bezettingsGeschiedenis contain? When trackOccupancyHistory is enabled, each facility record gets an array of past {timestamp, occupancyPercent, vacantSpaces} points (oldest first, capped at maxHistoryPoints), built up across scheduled runs via the actor's key-value store. Only facilities with real-time data get history points.

Also by this developer:

  • ../nl-waterstanden-monitor โ€” same profile: a real-time Dutch open-government-data monitoring feed, no login/API key required.
  • PDOK Adres Geocoding & Buurtdata โ€” geocode parking facility addresses to get coordinates and neighbourhood context.
  • NL Milieuzones & Zero-Emissiezones Monitor โ€” same profile: a direct, authentication-free NDW road-traffic-data feed, no scraping involved.
  • NL Ziekenhuis Wachttijden Monitor โ€” same profile: a direct, authentication-free Dutch government REST feed, no scraping involved.

Keywords: nederland parkeren, parkeertarieven, parkeergarage beschikbaarheid, real-time parking availability netherlands, RDW open data, nationaal parkeer register, parking API netherlands, MCP parking tool.

Keywords

netherlands, parking, parking-rates, parking-availability, open-data, rdw, real-time, mcp-tool

Changelog

0.3.2 - Bugfix

  • The change-detection snapshot is now merged with the previous run's snapshot instead of being fully replaced, matching the occupancy-history store's existing merge behaviour. Previously, running the actor with a different query/facilityIds between scheduled runs could wipe the tracked status of facilities left out of that run, causing a later run to miss a real availability-change-alert.

0.3.1 - Bugfix

  • Fixed status_changed detection and trackOccupancyHistory never seeing prior-run state: the actor was reading/writing its snapshot/history to Apify's per-Run default key-value store, which is not shared between separate runs. Now uses a named, persistent key-value store. A new baseline will be captured on the next run.

0.3.0

  • Added trackOccupancyHistory (opt-in) โ€” builds up an occupancy time series per facility across scheduled runs, exposed as bezettingsGeschiedenis. New occupancy-history-point event ($0.005), only charged for facilities with real-time data that got a new point this run.

0.2.0

  • Added evLaadpuntenCapaciteit โ€” EV-charging-point capacity, extracted separately from the general capacity field (which some facilities' static feed conflates with EV capacity). null when no specification has a chargingPointCapacity value; 0 is a real "no EV charging points" value, not an absence. No pricing change.

0.1.0 - Initial release

  • Tariff simplification (weekday-duplicated rules collapsed into unique price structures with computed โ‚ฌ/hour rate)
  • Live availability normalization (available / nearly_full / full / closed)
  • Change detection between runs (status_changed alerts via Pay-Per-Event)
  • Facility search by name (query) or exact facilityIds