UK Planning Applications - Per Application Entity

The UK's planning applications from the national Planning Data platform (planning.data.gov.uk) as clean, per-application records - reference, site point, the entry/start/end/decision dates, typology, quality and the local planning authority. Application events, not people.

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.

Coverage and volume

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. Because the platform ingests from every local planning authority in England that publishes to it, the set grows as authorities are onboarded and as applications are added.

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.

Distinct from planning-constraints

This dataset is the applications view. The fleet's uk-planning-constraints product draws from the same host but a different dataset - the designations that constrain development (conservation areas, flood zones, listed buildings, tree preservation orders and the like). Constraints describe the land; applications describe what someone asked to build on it. They share the platform and its geography but not a single record: joining them by site is a real analysis (which applications sit inside which constraints), which is exactly why they are two cells and not one.

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 buys this, and how they use it

This cell is bought by teams that need the source's full published set as a typed, keyed table they can hold and refresh, rather than a page they scrape. Market-intelligence and lead-generation teams use it to size a market and track who is active in it; analysts and journalists use it to build a longitudinal series that the source's own portal does not expose; data engineers use it as a clean upstream feed into a warehouse, keyed so it upserts without duplication. The common thread is that the record grain and the stable key are chosen so the output is a building block, not a one-off export: you run it on a schedule, keep the delta, and join it to your other sources on the identifiers it preserves verbatim.

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) the fleet 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 re-running is a cheap upsert rather than a re-import, 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.

Sibling Actors

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 door, so the data is as fresh as the source publishes, 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 a stable id, so the data loads without a cleaning pass, diffs cleanly between runs, and upserts into a table you maintain over time; re-running keeps that table current without re-paying for rows you already hold, and each receipt reconciles delivered against charged. Because the source's own identifiers are preserved verbatim, the dataset joins cleanly onto other sources keyed on the same identifier.

Scaling and scheduling

Set Maximum records low to sample the shape of the data cheaply, then raise it once the cell fits your use. The Actor delivers incrementally and streams its source, so memory stays flat regardless of how many records you request, and you are billed only for what is delivered. Because the source republishes on its own cadence, a scheduled run keeps a downstream table current: new and changed records upsert over the old ones on the stable key, and the observed_at stamp on every record tells you when each was last seen live. There is no subscription and no minimum - the per-record price and the record cap together mean the spend on any run is known in advance and matched exactly to the data you receive.