UK Planning Applications — Camden, Worthing, Adur & Doncaster (to Sep 2025)

Planning applications from the government Planning Data platform (planning.data.gov.uk) as clean, per-application records - reference, site point, decision date and the council's decision wording. Application events, not people.

Coverage, checked live on 30 Sep 2026: four councils — London Borough of Camden (77,499 applications), Worthing (13,629), Adur (7,585) and Doncaster (1,914) — 100,627 in all. The platform's newest entries were loaded in September 2025 and the latest decision date is September 2025, so this is not a live feed of every English council. The run receipt reports the platform's own total on every run, so any new council or newer data shows up there.

Who buys this and for what job

• Builders, trades and building-products suppliers finding new UK planning applications as sales leads.
• Property developers and analysts tracking planning application data and decisions by council.
• Proptech products that need planning records in clean form.

Buyers usually search for this as "uk planning applications" or "planning application data".

What one record represents

The source is the government Planning Data platform's entity API, filtered to the planning-application dataset. Each record is one planning-application entity: its local-authority reference, the dataset prefix, the platform entity id, the entity name, its typology, the organisation-entity id of the local planning authority that owns it, a representative geographic point for the site, a data-quality flag, and the entry, start, end and decision dates. It is the application-event view: what was applied for, where, under which authority, and when it moved through its dates.

Sample output

Real rows from a live run of this actor (first 5 rows, selected columns).

One full record from the same run, exactly as delivered:

{
  "reference": "23/00002/FUL",
  "prefix": "planning-application",
  "entity": "10000000000",
  "name": null,
  "typology": "geography",
  "organisation_entity": "109",
  "point": null,
  "quality": null,
  "entry_date": "2025-05-30",
  "start_date": null,
  "end_date": null,
  "decision_date": "2023-05-09",
  "source": "planning.data.gov.uk - planning-application dataset",
  "source_dataset": "planning-application",
  "licence": "Open Government Licence v3.0 (OGL v3.0). You are free to copy, publish, distribute, adapt and exploit the information commercially and non-commercially, provided you acknowledge the source with the required attribution statement and licence link.",
  "attribution": "Contains public sector information from planning.data.gov.uk licensed under the Open Government Licence v3.0",
  "caveat": "One record per planning-application entity from the UK national Planning Data platform: reference, prefix, site geometry point, quality, the entry/start/end/decision dates, typology and the organisation-entity (the local planning authority). The free-text `description` and the heavy WKT `geometry` are dropped; the entity API carries no applicant/agent name. Coverage: the four councils the platform holds (Camden, Worthing, Adur, Doncaster), with entries loaded up to September 2025.",
  "observed_at": "2026-09-25T17:26:33Z"
}

Search by council, decision and place

Question: which applications has Worthing refused since the start of 2024, newest first?

{"councils": ["Worthing"], "decidedFrom": "2024-01-01", "decisions": ["refuse"], "newestFirst": true, "maxRecords": 10}

Run on 30 Sep 2026 this read all 13,629 Worthing records (about a minute), found 89 refusals decided since 2024 and returned the newest 10 (10 × $0.05 = $0.50 on Apify's Free plan):

Reference	Decided	Decision
AWDM/0739/25	2025-09-04	Refuse (Delegated)
AWDM/0796/25	2025-09-02	Refuse (Delegated)
AWDM/0791/25	2025-08-01	Refuse (Delegated)
AWDM/1407/24	2025-07-31	Refuse (Delegated)
AWDM/0307/25	2025-07-09	Refuse (Delegated)

Search options (all optional; an application must match every option you set):

• Councils (councils) — Camden, Worthing, Adur, Doncaster (or ids 90, 382, 26, 109). Filtered at the source.
• Decided from / to (decidedFrom, decidedTo) — decision-date range, a date or a year.
• Decision (contains) (decisions) — words in the council's decision: Worthing and Adur write Approve / Refuse / Withdrawn in planning_decision; Camden writes Granted / Refused / Withdrawn Decision in planning_decision_type. Doncaster publishes no decision wording.
• Near a site (latitude, longitude, radiusKm, default 1 km) — adds distance_km. Doncaster rows carry no location.
• Newest decision first (newestFirst) — reads every record in scope and keeps the newest.

Filters are applied before the record limit. The status message says whether every record for the chosen councils was read or the run stopped at maxRecords first (then more may match). With no search option the actor sweeps the dataset exactly as before. Two fields were added to every record on 30 Sep 2026: planning_decision and planning_decision_type, the council's own wording, verbatim.

Coverage and volume

Default changed on 30 Sep 2026: if you leave maxRecords out, a run now returns up to 10 records (it was 500). Set maxRecords yourself to get more — the maximum is unchanged.

The platform reports an exact total for the dataset - about 100,627 planning-application entities at the time of writing - and the Actor exposes that count on every run's receipt (reported_total). You raise Maximum records to pull the whole set or lower it to sample; paging is by the entity API's own limit/offset, so a run is a stable sweep of the dataset. The set only grows when the platform onboards another council or loads newer applications; as of 30 Sep 2026 it holds the four councils listed at the top, with nothing newer than September 2025.

Person data: description dropped, no applicant field

A planning application can name an applicant and an agent. This cell is built to sell application events, not the people behind them, and it removes personal data structurally. The free-text description field - which can paraphrase who is doing what - is dropped and never delivered, as is the heavy WKT geometry blob. The entity API at this grain carries no applicant or agent name field at all; the delivered record is limited to the reference, the site point, the dates, the typology and the authority. A blocklist assertion rejects any applicant/agent/contact field before delivery, so if the upstream schema ever changed to include one, the run would fail rather than leak it. What you get is a person-free record of which application, at which site, under which authority, reached which decision on which date.

Licence

Open Government Licence v3.0 (OGL v3.0). You are free to copy, publish, distribute, adapt and exploit the information commercially and non-commercially, provided you acknowledge the source with the required attribution statement and licence link. The required attribution statement rides on every record.

Who uses this, and for what

This is a historical, local dataset: four councils' applications as the government platform holds them, with decisions up to September 2025. It suits jobs that look back, not jobs that need this week's applications:

• Planning consultants and architects checking how Camden (Granted / Refused wording) or Worthing and Adur (Approve / Refuse) have decided similar applications, or how often they refuse, before advising a client.
• Property buyers, surveyors and conveyancing researchers pulling the recorded planning history on and around a site with the near-a-point search (Camden, Worthing and Adur rows carry a location; Doncaster rows do not).
• Researchers and journalists studying refusal and withdrawal patterns in these four councils over time.

It is not a source of current applications or of any other council; for those you need each council's own register.

Field-by-field, and why the grain is what it is

Every field in the record is either a source-native identifier, a source-native attribute, or one of the six provenance fields (source, source_dataset, licence, attribution, caveat, observed_at) this Actor attaches to every record. Nothing is derived or inferred beyond the small, documented transforms noted above, and nothing is dropped silently: the person-handling section spells out exactly which fields are excluded and why. The grain - one record per the natural unit of the source - is deliberate: it keeps each row independently meaningful, keeps the key stable across runs so a re-run upserts cleanly rather than duplicating rows, and lets you aggregate up to whatever unit you need without having to unpick a pre-joined table. If you need a different grain, you compose it downstream from these rows; the cell's job is to deliver the atomic, person-safe, licence-clean records that everything else is built from.

Reconciling counts honestly

Where the live count differs from any previously published figure, the live measure is the honest one and is what this listing quotes; sources re-issue and consolidate their data over time, so a figure drifts. The run receipt always states what was actually delivered and charged and confirms the two agree, so every run is auditable against itself regardless of what any external index expected.

Provenance and compliance

Every run reads the door host's robots.txt at runtime; the gate result (URL, status, byte length and, where a policy is served, its SHA-256) is written to the run's RUN_RECEIPT. Where the host serves no applicable robots rule, or redirects its policy to another host, the gate records that (flagged) and proceeds on the licence, which grants re-use. The endpoint is keyless. The Actor never bypasses a block or fetches through a mirror, and it reads only the public listing endpoint - never a per-record detail page.

Data quality and freshness

Numeric columns are delivered as real numbers and every other column as a string or null, so the dataset loads without a cleaning pass. Delivery is keyed on a stable source identifier, so the data is safe to diff, deduplicate or upsert. Every run re-reads the live platform, so the data is as fresh as the platform publishes (on 30 Sep 2026 its newest entries date from September 2025), and each record's observed_at stamp dates the snapshot. The run's RUN_RECEIPT records the source URL and how many records were delivered and charged, and confirms charge_equals_delivered.

Billing, delivery and joins

Pricing is per record: you are billed only for records the Actor actually delivers, with the charge raised after each record is pushed (push-then-charge), so a failed or empty run costs nothing. The Maximum records cap bounds every run, so you control spend precisely - sample cheaply, then raise it. Every record is a flat, typed object keyed on the platform's stable entity id, so it diffs and upserts cleanly into a table you keep. Each run charges for every record it delivers, including records you already hold from an earlier run. Each receipt reconciles delivered against charged.

Scaling and scheduling

Set Maximum records low to sample the shape of the data cheaply, then raise it once the data fits your use. The Actor streams its source, so memory stays flat however many records you request. A schedule is not useful at the moment: the platform's newest entries date from September 2025, so repeat runs return the same records. Every run's receipt gives the platform's own total (reported_total); if that number changes, the platform has loaded a new council or newer applications.