# UK Planning Applications Monitor: New, Pending & Decided (`wallman_3rd/uk-planning-monitor`) Actor Track new, pending, and decided UK planning applications (extensions, new builds, change of use, solar) from planning.data.gov.uk. Covers Camden, Worthing, Adur, and Doncaster today, expanding as the register onboards councils. Deduplicated, with change detection and lead alerts. - **URL**: https://apify.com/wallman\_3rd/uk-planning-monitor.md - **Developed by:** [Z W](https://apify.com/wallman_3rd) (community) - **Categories:** Lead generation, Automation - **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks - **User rating**: No ratings yet ## Pricing from $3.00 / 1,000 results This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events. Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#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. In JavaScript/TypeScript projects, use official [JavaScript/TypeScript client](https://docs.apify.com/api/client/js/docs.md): ```bash npm install apify-client ``` In Python projects, use official [Python client library](https://docs.apify.com/api/client/python/docs.md): ```bash pip install apify-client ``` In shell scripts, use [Apify CLI](https://docs.apify.com/cli/docs.md): ````bash # MacOS / Linux curl -fsSL https://apify.com/install-cli.sh | bash # Windows irm https://apify.com/install-cli.ps1 | iex ```bash In AI frameworks, you might use the [Apify MCP server](https://docs.apify.com/integrations/mcp.md). If your project is in a different language, use 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 ## UK Planning Applications Monitor **Track new, pending, and decided UK planning applications in one clean, deduplicated feed, with automatic change detection between runs.** This Actor aggregates planning applications (extensions, new builds, change of use, solar/PV, tree works, and more) from the official [planning.data.gov.uk](https://www.planning.data.gov.uk) central register, normalizes them to a single schema, removes duplicates, and reports exactly what changed since the last run. A **new planning application near a location is a high-intent lead signal.** Someone is about to build, extend, convert, or install. That is the moment construction suppliers, solar and EV installers, architects, PropTech firms, and estate agents want to reach a property owner. This Actor turns a scattered government register into a monitored feed of those signals. > **Current coverage:** the central register today carries four councils in full, **Camden, Worthing, Adur, and Doncaster** (see the [Coverage](#coverage) table). Coverage grows automatically as the government register onboards more councils. Check the Input tab for the live list before you run. ### Why use the UK Planning Applications Monitor? - **Lead generation:** surface fresh applications the day they appear, filtered to the category you sell into (solar installers want `solar_pv`, builders want `extension` and `new_build`, sign firms want `advertisement`). - **Change detection built in:** the first run builds a baseline, every later run reports only what is new, updated, decided, or withdrawn. No diffing on your side. - **Deduplicated and normalized:** one schema across councils, one record per application, stable ids so you can join against your CRM. - **Self-healing source health:** every run reports per-council health and flags a `suspicious_zero` (a council that returned data last run and nothing this run) so a silent upstream break is caught immediately. - **Runs on the Apify platform:** schedule it, hit it via API, wire the results into your integrations, and let the platform handle retries and storage. ### How to use it 1. Click **Try for free**. 2. (Optional) Pick which **councils** to include and which **categories** you care about. Leave both empty to get everything. 3. (Optional) Turn on **Monitor mode (output only changes)** and schedule the Actor (for example, daily). The first run captures a baseline, later runs return only changes. 4. Click **Start**. Results appear in the **Dataset** tab, downloadable as JSON, CSV, Excel, or HTML. ### Coverage This Actor reads the UK government's central planning-application register. That register is an active data programme rather than a complete national feed: today it carries four councils in full, with deep history and current pending applications. | Council | Code | Approx. applications | | --- | --- | --- | | London Borough of Camden | `CMD` | 77,000+ | | Worthing Borough Council | `WOT` | 13,600+ | | Adur District Council | `ADU` | 7,500+ | | Doncaster Metropolitan Borough Council | `DNC` | 1,900+ | As the government register onboards more councils, they are added here. Field richness varies by council: some supply full street address, coordinates, a direct portal link, and the filed date, others supply the reference, description, and decision date only. Every enrichment field is optional and returned as `null` when a council does not provide it. ### Input All inputs are optional. Configure them in the **Input** tab or via the API. | Field | Type | Description | | --- | --- | --- | | `councils` | array | Council short codes to include (e.g. `["CMD", "WOT"]`). Empty = all covered councils. | | `includePending` | boolean | Include applications with no decision yet (the highest-intent lead signal). Default `true`. | | `includeDecided` | boolean | Include decided and withdrawn applications. Default `true`. | | `categories` | array | Filter to derived categories (e.g. `["solar_pv", "extension"]`). Empty = all. | | `onlyOutputChanges` | boolean | Monitor mode: push only new/changed/removed applications. Default `false`. | | `maxRecordsPerSource` | integer | Cap of newest records pulled per council. `0` = unlimited. Default `5000`. | | `suppressInitialChanges` | boolean | On the first run, do not emit a change for every application. Default `true`. | | `freshLeadAlertDays` | array | Age-since-filed windows for the `FRESH_LEADS` report. Default `[7, 14, 30]`. | | `webhookUrl` | string | HTTPS endpoint that receives change events as a POST after each run. | | `testMode` | boolean | Cap every council at 3 records and skip the baseline update. A free smoke test. | ### Output Each record is one planning application: ```json { "id": "pa_382_awdm-0898-25", "sources": ["planning-data-gov"], "recordType": "planning_application", "reference": "AWDM/0898/25", "council": "Worthing Borough Council", "councilId": 382, "councilWebsite": "https://www.adur-worthing.gov.uk", "description": "Application for consent under Worthing Tree Preservation Order No.5 of 1991 to fell and replace 17 diseased Ash trees of group A1.", "appCategory": "trees", "status": "pending", "statusRaw": null, "decisionType": null, "receivedDate": "2025-07-08", "decisionDate": null, "registerDate": "2025-09-07", "address": { "text": "Moonraker 20 Gorse Lane Worthing West Sussex BN13 3BX", "postcode": "BN13 3BX", "country": "GB" }, "coordinates": { "lat": 50.851179, "lng": -0.406692 }, "url": "http://planning.adur-worthing.gov.uk/online-applications/applicationDetails.do?activeTab=summary&keyVal=SZ271DCBIHN00", "entity": 10000100631, "typology": "geography", "lastScraped": "2026-07-22T00:00:00.000Z" } ```` You can download the dataset in various formats such as JSON, HTML, CSV, or Excel. #### Data fields | Field | Description | | --- | --- | | `reference` | The council's own application reference. | | `council` / `councilId` | Council name and its register organisation id. | | `description` | The proposal text as filed. | | `appCategory` | Derived category: `extension`, `new_build`, `change_of_use`, `solar_pv`, `trees`, `listed_building`, `advertisement`, `demolition`, or `other`. | | `status` | `pending`, `decided`, or `withdrawn`. | | `receivedDate` / `decisionDate` / `registerDate` | When filed, when decided, and when the register first listed it. | | `address` | Free-text address plus extracted UK postcode, where the council supplies it. | | `coordinates` | `{ lat, lng }` where the council supplies a location. | | `url` | Direct link to the council portal page, or the register entry as a fallback. | #### Extra outputs (key-value store) - `CHANGES`: the full change set for the run plus a summary count. - `RUN_HEALTH`: per-council status, including the `suspicious_zero` silent-break flag. - `FRESH_LEADS`: applications bucketed by how recently they were filed. - `COVERAGE`: a check of whether the central register has started carrying a council not yet built in. If it has, the new council ids are listed here (and sent to your webhook), so you know the moment more coverage becomes available. ### How change detection works The Actor stores a compact fingerprint of every application in a named, cross-run store. On each run it compares the current data to that baseline and emits typed events: `new_application`, `decision_made` (pending to decided), `status_changed`, `updated`, and `removed`. Run it on a schedule with **Monitor mode** on and each run returns only what moved. Point `webhookUrl` at your endpoint to be notified the moment there are changes. ### Pricing This Actor is pay-per-result: you pay for the applications it returns. Planning data is high volume, so the price per result is set low. In **Monitor mode** you pay only for the handful of applications that actually changed on each scheduled run, which keeps ongoing monitoring inexpensive. Use `testMode` for a free smoke test before a full run. ### Tips - **For lead generation, keep `includePending` on and set `categories`** to your niche so you only pay for relevant applications. - **For a monitoring workflow, turn on `onlyOutputChanges` and schedule daily.** The first run is your baseline; later runs are small and cheap. - **Raise `maxRecordsPerSource` to `0`** when you want the full historical backfill for a council; leave it capped for fast, current-focused runs. ### FAQ **Where can I get UK planning application data?** This Actor. It aggregates planning applications from UK councils into one structured feed and detects new and changed applications between runs. **Which councils are covered?** It launches with the councils available through the planning.data.gov.uk central dataset and expands over time. Check the input for the current list. **How do I find new planning applications (solar, extensions, change of use)?** Turn on monitor mode and add a `webhookUrl`. Each new application is emitted as an event, with a category classifier (solar\_pv, extension, change\_of\_use, and more). **What data does each record include?** Application reference, description, category, status (pending, decided, or withdrawn), council, dates, and location where the source publishes it. **Is this official and legal data?** It uses public UK planning data published under the Open Government Licence. It accesses no private data. ### Disclaimers and support **Where does the data come from?** The official UK government planning-application register at planning.data.gov.uk. This Actor does not scrape behind logins or bypass access controls. **Is scraping this legal?** The register is published as open government data. As with any data product, you are responsible for using the output in line with the source's terms and applicable law, including how you contact any individuals. **Why are some fields empty?** The central register carries different fields for different councils. Missing fields are returned as `null` rather than omitted, so your schema stays stable. **A council I need is not covered.** Coverage tracks the government register as it onboards councils. Use the **Issues** tab to request a council, and to report anything that looks wrong. # Actor input Schema ## `councils` (type: `array`): Which councils to include, by short code. The planning.data.gov.uk central register currently carries: DNC (Doncaster), ADU (Adur), WOT (Worthing), CMD (Camden). Leave empty to include every council the register covers. ## `includePending` (type: `boolean`): Include applications that have no decision yet, the high-intent 'work about to start' signal for suppliers and installers. ## `includeDecided` (type: `boolean`): Include applications that already carry a decision date. ## `categories` (type: `array`): Filter to specific derived categories (e.g. extension, new\_build, change\_of\_use, solar\_pv, trees, listed\_building, advertisement, demolition, other). Leave empty for all. ## `onlyOutputChanges` (type: `boolean`): Push only new/changed/removed applications to the dataset instead of the full list. Ideal for a scheduled run: the first run builds the baseline, each later run reports only what changed. ## `maxRecordsPerSource` (type: `integer`): In full mode, cap the dataset output to this many of the freshest applications per council (0 = unlimited; a full pull is roughly 100k rows). Change detection always reads the whole register regardless, so monitor mode is unaffected. Kept modest by default so a first run is quick and cheap; raise it for full historical coverage. ## `suppressInitialChanges` (type: `boolean`): On the very first run (no baseline yet), don't emit a 'new' event for every application. Leave on to avoid a flood. ## `freshLeadAlertDays` (type: `array`): Age-since-filed windows for the FRESH\_LEADS report, the newest applications are the hottest leads. ## `webhookUrl` (type: `string`): HTTPS endpoint to receive change events as a POST after each run (fires only when there are changes and a baseline exists). ## `checkCoverage` (type: `boolean`): Each run, cheaply check whether the central register has started carrying a council not yet built in, and report it in the COVERAGE output (and webhook). Lets you know the moment new coverage is worth adding. ## `stateStoreName` (type: `string`): Name of the named key-value store that holds this monitor's cross-run baseline. Leave blank to use the shared default. Set a distinct value when you run two schedules or tasks with different inputs so they keep separate baselines instead of overwriting each other. ## `testMode` (type: `boolean`): Cap every source at 3 records and skip the snapshot update. Free smoke test to confirm the Actor works before a full run. ## Actor input object example ```json { "councils": [], "includePending": true, "includeDecided": true, "categories": [], "onlyOutputChanges": false, "maxRecordsPerSource": 5000, "suppressInitialChanges": true, "freshLeadAlertDays": [ 7, 14, 30 ], "checkCoverage": true, "testMode": false } ``` # 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 '' with your token const client = new ApifyClient({ token: '', }); // Prepare Actor input const input = { "councils": [], "categories": [] }; // Run the Actor and wait for it to finish const run = await client.actor("wallman_3rd/uk-planning-monitor").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 '' with your token. client = ApifyClient("") # Prepare the Actor input run_input = { "councils": [], "categories": [], } # Run the Actor and wait for it to finish run = client.actor("wallman_3rd/uk-planning-monitor").call(run_input=run_input) # Fetch and print Actor results from the run's dataset (if there are any) print("💾 Check your data here: https://console.apify.com/storage/datasets/" + run["defaultDatasetId"]) for item in client.dataset(run["defaultDatasetId"]).iterate_items(): print(item) # 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start ``` ## CLI example ```bash echo '{ "councils": [], "categories": [] }' | apify call wallman_3rd/uk-planning-monitor --silent --output-dataset ``` ## MCP server setup ```json { "mcpServers": { "apify": { "command": "npx", "args": [ "mcp-remote", "https://mcp.apify.com/?tools=wallman_3rd/uk-planning-monitor", "--header", "Authorization: Bearer " ] } } } ``` ## OpenAPI specification ```json { "openapi": "3.0.1", "info": { "title": "UK Planning Applications Monitor: New, Pending & Decided", "description": "Track new, pending, and decided UK planning applications (extensions, new builds, change of use, solar) from planning.data.gov.uk. Covers Camden, Worthing, Adur, and Doncaster today, expanding as the register onboards councils. Deduplicated, with change detection and lead alerts.", "version": "0.1", "x-build-id": "EYpIK5ghS82DYwcsU" }, "servers": [ { "url": "https://api.apify.com/v2" } ], "paths": { "/acts/wallman_3rd~uk-planning-monitor/run-sync-get-dataset-items": { "post": { "operationId": "run-sync-get-dataset-items-wallman_3rd-uk-planning-monitor", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for its completion, and returns Actor's dataset items in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } }, "/acts/wallman_3rd~uk-planning-monitor/runs": { "post": { "operationId": "runs-sync-wallman_3rd-uk-planning-monitor", "x-openai-isConsequential": false, "summary": "Executes an Actor and returns information about the initiated run in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/runsResponseSchema" } } } } } } }, "/acts/wallman_3rd~uk-planning-monitor/run-sync": { "post": { "operationId": "run-sync-wallman_3rd-uk-planning-monitor", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for completion, and returns the OUTPUT from Key-value store in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } } }, "components": { "schemas": { "inputSchema": { "type": "object", "properties": { "councils": { "title": "Councils", "type": "array", "description": "Which councils to include, by short code. The planning.data.gov.uk central register currently carries: DNC (Doncaster), ADU (Adur), WOT (Worthing), CMD (Camden). Leave empty to include every council the register covers.", "default": [], "items": { "type": "string" } }, "includePending": { "title": "Include pending applications", "type": "boolean", "description": "Include applications that have no decision yet, the high-intent 'work about to start' signal for suppliers and installers.", "default": true }, "includeDecided": { "title": "Include decided applications", "type": "boolean", "description": "Include applications that already carry a decision date.", "default": true }, "categories": { "title": "Application categories", "type": "array", "description": "Filter to specific derived categories (e.g. extension, new_build, change_of_use, solar_pv, trees, listed_building, advertisement, demolition, other). Leave empty for all.", "default": [], "items": { "type": "string" } }, "onlyOutputChanges": { "title": "Monitor mode, output only changes", "type": "boolean", "description": "Push only new/changed/removed applications to the dataset instead of the full list. Ideal for a scheduled run: the first run builds the baseline, each later run reports only what changed.", "default": false }, "maxRecordsPerSource": { "title": "Max records per council (full mode output)", "minimum": 0, "type": "integer", "description": "In full mode, cap the dataset output to this many of the freshest applications per council (0 = unlimited; a full pull is roughly 100k rows). Change detection always reads the whole register regardless, so monitor mode is unaffected. Kept modest by default so a first run is quick and cheap; raise it for full historical coverage.", "default": 5000 }, "suppressInitialChanges": { "title": "Suppress changes on first run", "type": "boolean", "description": "On the very first run (no baseline yet), don't emit a 'new' event for every application. Leave on to avoid a flood.", "default": true }, "freshLeadAlertDays": { "title": "Fresh-lead alert windows (days)", "type": "array", "description": "Age-since-filed windows for the FRESH_LEADS report, the newest applications are the hottest leads.", "default": [ 7, 14, 30 ] }, "webhookUrl": { "title": "Webhook URL", "type": "string", "description": "HTTPS endpoint to receive change events as a POST after each run (fires only when there are changes and a baseline exists)." }, "checkCoverage": { "title": "Check for newly-added councils", "type": "boolean", "description": "Each run, cheaply check whether the central register has started carrying a council not yet built in, and report it in the COVERAGE output (and webhook). Lets you know the moment new coverage is worth adding.", "default": true }, "stateStoreName": { "title": "State store name (advanced)", "type": "string", "description": "Name of the named key-value store that holds this monitor's cross-run baseline. Leave blank to use the shared default. Set a distinct value when you run two schedules or tasks with different inputs so they keep separate baselines instead of overwriting each other." }, "testMode": { "title": "Test mode", "type": "boolean", "description": "Cap every source at 3 records and skip the snapshot update. Free smoke test to confirm the Actor works before a full run.", "default": false } } }, "runsResponseSchema": { "type": "object", "properties": { "data": { "type": "object", "properties": { "id": { "type": "string" }, "actId": { "type": "string" }, "userId": { "type": "string" }, "startedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "finishedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "status": { "type": "string", "example": "READY" }, "meta": { "type": "object", "properties": { "origin": { "type": "string", "example": "API" }, "userAgent": { "type": "string" } } }, "stats": { "type": "object", "properties": { "inputBodyLen": { "type": "integer", "example": 2000 }, "rebootCount": { "type": "integer", "example": 0 }, "restartCount": { "type": "integer", "example": 0 }, "resurrectCount": { "type": "integer", "example": 0 }, "computeUnits": { "type": "integer", "example": 0 } } }, "options": { "type": "object", "properties": { "build": { "type": "string", "example": "latest" }, "timeoutSecs": { "type": "integer", "example": 300 }, "memoryMbytes": { "type": "integer", "example": 1024 }, "diskMbytes": { "type": "integer", "example": 2048 } } }, "buildId": { "type": "string" }, "defaultKeyValueStoreId": { "type": "string" }, "defaultDatasetId": { "type": "string" }, "defaultRequestQueueId": { "type": "string" }, "buildNumber": { "type": "string", "example": "1.0.0" }, "containerUrl": { "type": "string" }, "usage": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "integer", "example": 1 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } }, "usageTotalUsd": { "type": "number", "example": 0.00005 }, "usageUsd": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "number", "example": 0.00005 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } } } } } } } } } ```