UK Planning & Building Control Applications Scraper

Weekly Building Control and Planning application lists from UK council Idox Public Access portals, normalised into one flat schema across councils — including the Building Control register no other Apify actor covers.

A failed or empty run costs $0.00005 (the platform start fee), not $0. Per-row charges fire only after rows are actually written to your dataset.

Who this is for

• Builders & loft/conversion companies — Building Control deposits are full plans deposited weeks before work starts; that register is not in any national planning feed.
• Building material suppliers — watch permits + BC deposits by council and time outreach to when work is actually commencing.
• Lead-gen teams — run planning with includeContacts: true and get the agent name/email/phone behind each application, from the council's own register.
• Property developers & investors — monitor planning decisions and BC starts across councils in one normalised dataset.
• Researchers & journalists — statutory register data, republished as published, per-week slices back 8 weeks.

What you get

One row per application, identical schema for every council:

field	meaning
council, council_name, portal_host	which council's register
register_type	building_control or planning
reference	council application reference (stable id)
proposal	description of works as published
address	site address as published
status	status at harvest time
event_type / event_date	list event: deposited (BC) / validated (planning) / decided / …
week_start	week label of the weekly list
key_val	portal key — dedupe across runs on this (or reference)
detail_url	public portal page for the application
harvested_at	UTC harvest timestamp

With includeContacts: true (v0.4), each planning row is enriched from the council's own contacts sub-tab with agent_name, agent_email, agent_phone, agent_address (and the applicant_* equivalents where published) — the named party behind the application, straight from the statutory register. Coverage is council-specific: Tameside and Leeds publish agent contacts openly; Bury publishes none ("There are no contacts associated with this case"). Where a council publishes nothing, the row says contacts_published: "no" — an honestly empty field, never a guess. Building Control pages carry no contacts sub-tab, so BC rows are marked contacts_published: "no" without an extra request.

Input parameters

field	type	default	meaning
councils	string[]	required	council slugs, e.g. ["leeds","tameside"]
registers	string[]	both	building_control, planning, or both
weeksBack	number	0	0 = current week only; up to 8 previous weekly lists
maxRowsPerCouncil	number	200	safety cap per council+register; a loud WARNING logs if the portal lists more
includeDetails	boolean	false	open each details page — fills event_date and missing fields. Slower
includeContacts	boolean	false	fetch the contacts sub-tab per planning row (lead-gen). One paced request per row
strictMode	boolean	false	true: any portal error fails the run (start fee only). false: skip and continue

Deduplicate across runs on key_val + council (or reference + council).

Covered councils (v0.2)

12 councils, every portal live-verified end-to-end (form → list → rows). Building Control + Planning on the same Idox portal: Leeds, Sheffield, Bradford, Tameside, Bury, Sefton, St Helens, Solihull, Cheltenham, Luton, Cheshire West and Chester. Newham publishes Planning only.

Request a council by opening an Issue — Idox Public Access portals are template-driven and onboarding is fast.

Input example

{
  "councils": ["leeds"],
  "registers": ["building_control"]
}

Both fields accept arrays; run several councils and registers in one call. Rows from all councils land in one dataset with the identical schema.

Sample output (real run, 2026-10-02)

Rendered from an unedited platform dataset — councils ["leeds","tameside"], register building_control, week of 28 Sep 2026, capped at 15 rows per council (30 rows total, each billed at $0.02):

Every cell comes from run A6AP8wRWh4kBKO6PJ (2026-10-02, build 0.5.1) — the dataset only rendered as a table. The log's honest cap warning is visible in the run itself: portals listed 154 (leeds) and 19 (tameside) applications for that week; delivery stopped at maxRowsPerCouncil=15.

Raw JSON row from that same run:

[
  {
    "council": "leeds",
    "council_name": "Leeds City Council",
    "portal_host": "publicaccess.leeds.gov.uk",
    "register_type": "building_control",
    "reference": "26/04014/DALBN",
    "proposal": "Internal wall removal and insert steel beam",
    "address": "5 Barfield Avenue Yeadon Leeds LS19 7SH",
    "status": "Pending Consideration",
    "event_type": "deposited",
    "event_date": "2026-10-28",
    "week_start": "28 Sep 2026",
    "key_val": "TM88W6JB3D500",
    "detail_url": "https://publicaccess.leeds.gov.uk/online-applications/buildingControlDetails.do?keyVal=TM88W6JB3D500&activeTab=summary",
    "harvested_at": "2026-10-02T16:42:55+00:00"
  }
]

Planning row with includeContacts: true (real Tameside row, week 21 Sep 2026):

{
  "council": "tameside",
  "register_type": "planning",
  "reference": "26/00741/FUL",
  "proposal": "Erection of a single storey bus driver's welfare unit.",
  "address": "Haughton Green Bus Stop Mancunian Road M34 7PD",
  "event_type": "validated",
  "event_date": "2026-09-23",
  "week_start": "21 Sep 2026",
  "key_val": "TLTLNPPUJ5Z00",
  "detail_url": "https://publicaccess.tameside.gov.uk/online-applications/applicationDetails.do?keyVal=TLTLNPPUJ5Z00&activeTab=summary",
  "harvested_at": "2026-09-26T22:41:15+00:00",
  "agent_name": "Laura Gerada",
  "agent_email": "enquiries@williams-architects.co.uk",
  "agent_phone": "01159455691"
}

Use with the Apify MCP server

Works out of the box with Apify's MCP server (@apify/actors-mcp-server) — scrape planning data straight from Claude, Cursor or any MCP client:

{
  "mcpServers": {
    "apify": {
      "command": "npx",
      "args": ["-y", "@apify/actors-mcp-server",
               "halobartku/uk-planning-building-control-scraper"]
    }
  }
}

Pricing — and why it's $0.02 per application

actor	per-application price	registers	applicant/agent contacts
devon_gtme/uk-planning-applications-planit	pay-per-result	planning only	not included — sold as a separate managed service ("message me with councils, volume and fields")
memo23/uk-planning-applications-scraper	$0.010 / result (free PlanIt API wrapper)	planning only	no (upstream returns "See source" placeholders)
this actor	$0.020 / application-harvested	planning + building control	yes — includeContacts: true, from the council's own portal

You pay a $0.00005 platform start fee per run, then $0.02 once per row delivered — per-row charges never fire on failure. A weekly single-council run (40–200 rows) costs $0.80–4.00 plus the start fee; the same coverage from the $0.05 competitor costs 2.5× more and still misses Building Control entirely. BC rows are the early signal: full plans deposited weeks before the planning application appears.

FAQ

Why Idox portals and not the national planning pipeline? PlanPipe-style national feeds cover planning applications only. Building Control deposits (structural alterations, steel insertions, demolitions) live on each council's Idox Public Access portal — that register is what this actor adds, and why builders/loft companies cannot get it elsewhere.

How fresh is the data? Each run harvests the live weekly list — typically published within a day or two of deposit. Run daily to catch councils that update mid-week.

How do I get only new applications? Deduplicate on key_val + council across runs; event_date lets you filter to the current week.

Can I add my council? Yes — open an Issue with the council name. Any Idox Public Access portal (100+ UK councils run Idox) is a small config addition, verified live before release.

What happens if a portal is down or changes? The run fails loudly with the council named — you pay only the $0.00005 start fee — and the next run retries. Partial results are still delivered and only those rows bill.

For AI agents & LLM apps

Compact reference for AI agents calling this actor via the Apify MCP server or the Apify API (actor: halobartku/uk-planning-building-control-scraper).

Purpose: Harvest the weekly Building Control and Planning application lists from UK council Idox Public Access portals — one normalised row per application (council, reference, proposal, site address, status, event type/date, portal link). Building Control deposits are the register no other Apify actor covers.

Minimal input:

{ "councils": ["leeds"], "registers": ["building_control"] }

Output: one row per application — council, council_name, portal_host, register_type (building_control|planning), reference, proposal, address, status, event_type, event_date, week_start, key_val, detail_url, harvested_at; with includeContacts also agent_name/agent_email/agent_phone (+ applicant_* where published, contacts_published marker).

Behaviors an agent should know:

• Both councils and registers accept arrays; rows from all councils land in one dataset with the identical schema.
• Deduplicate across runs on key_val + council (or reference + council); event_date filters to the current week.
• Supported councils (v0.2): Leeds, Sheffield, Bradford, Tameside, Bury, Sefton, St Helens, Solihull, Cheltenham, Luton, Cheshire West and Chester (BC + planning); Newham (planning only). More on request via the actor's Issues tab.
• A failing portal fails the run loudly with the council named — cost is the $0.00005 start fee only; partial results are still delivered and only those rows bill.
• Billing: $0.00005 platform start fee per run + pay-per-event application-harvested ($0.02/row) charged only after rows are written — failed or empty runs cost the start fee only.

Correctness — validated against the portals themselves

Actor output is re-verified against the live portal, not just "run completes". Latest check 2026-10-02: Leeds Building Control, week starting 28 Sep — portal's own result count said 154 applications; the actor returned 154/154 unique rows, exact match. This same check is what caught the v0.1.8 pagination bug and (2026-10-02) a retry-budget shortfall that silently skipped Leeds on flaky-500 days. A council that cannot be verified row-exact does not ship.

Changelog

0.6 - 2026-10-06: pricing-honesty README/PRICING repair, no code change. The README claimed failed/empty runs cost $0 / "never pay for a failed run"; live platform pricing bills a $0.00005 apify-actor-start fee on every run, failed ones included. All 6 README spots + PRICING.md + the store-card description now state the exact cost model ($0.00005 start + $0.02/row). src/ byte-identical to 0.5.3.

0.5.3 - 2026-10-04: a council portal that stops responding no longer fails the whole run. A read timeout on one portal used to escape the retry logic and end a multi-council run with no results. Now a timed-out request is retried once, then that council is skipped with a warning in the log and in the run status, the other councils are delivered, and the skipped council is not charged (no rows, no charge).

0.5 — 2026-10-02: reliability fix, found by the fresh-sample discipline. Leeds' portal served HTTP 500 four times in a row on cold sessions before serving normally (soft-throttle window); the old 3-retry budget exhausted and the whole council was silently skipped in multi-council runs (tameside delivered, leeds absent, run still SUCCEEDED). Retry budget 3→6 with longer backoff on 5xx. Re-validated live: leeds 154/154 rows unique vs the portal's own stated total, exact. README sample-output refreshed from E2E run on this build (leeds + tameside, week 28 Sep 2026).

0.4 — 2026-09-26: includeContacts — per-row applicant/agent enrichment from the council's own contacts sub-tab (agent_name, agent_email, agent_phone, agent_address, applicant_*, contacts_published marker). Verified live 2026-09-26 on Tameside (2/3 planning rows carry agent name+email+phone; 1/3 honestly empty), Leeds (agent company + mobile + email), Bury (publishes no contacts — returned as no, verified at source). includeDetails now also fills event_date from the details page (BC rows previously shipped with an empty date). Input documentation table added to this README.

0.3 — 2026-09-14: README-only. Sample-output section now leads with a rendered image of a real run's dataset (leeds + tameside, week 07 Sep 2026) with full provenance: run id, input, rows/fields disclosure, cap warning, per-row charge accounting. No code, schema or pricing changes.

0.1.9 — 2026-08-31: pagination fix #2, found by dated ground-truth validation. Some Idox portals (Bury) window their pager at 10 pages on page 1 even when the week holds more — the old code clamped pagination to the pager and silently delivered 100 of 197 rows for Bury's 24-Aug week (all billed). Now the portal's stated total drives pagination; a cap hit by maxRowsPerCouncil logs a loud WARNING instead of truncating silently; an empty page stops pagination safely. Re-validated live: 197/197 Bury, 21/21 Tameside, row-exact vs the portals' own counts. README corrected to the real council list (v0.1 text named five councils never in the build and omitted six that were). 0.1.6 — 2026-08-22: pagination fix. The portal's result-count phrase carries an inline </strong> (Showing 1-10</strong> of 76); our old count regex missed it, so multi-page weeks returned only page 1 (Leeds: 10 of 76 rows). Found by independent ground-truth validation, fixed, re-validated 76/76 + 18/18 rows exact vs same-minute portal HTML. If you ran this actor before 2026-08-22, re-run for complete weeks. 0.1 — 2026-08-20: initial public release. 12 councils, both registers, one normalised schema, per-row PAY-PER-EVENT pricing.

SEO keywords

uk building control applications scraper, building control register scraper, idox public access scraper, uk planning applications scraper, building control weekly list, building control deposits, building notices uk, structural alteration applications, uk planning weekly list, council planning register scraper, uk planning data api, construction leads uk, builder leads uk, loft conversion leads, property development leads uk, planning application monitoring, building control data export, uk council portals scraper, bury building control applications, tameside building control applications, bradford planning applications, sheffield building control, planning applications by council