If your pipeline depends on knowing about planning applications before anyone else does, somebody is opening council websites one at a time and copying out what changed. It is a full working day, every day, and it stops the moment that person is ill or on holiday. This is the page for the version that runs on its own.
London has 33 boroughs and they do not share a planning system. Seventeen run Idox, four run the Idox Citizen portal, and the rest are spread across Arcus, Northgate, Ocella, Agile, NEC and one genuine open data API. One borough blocks automated access altogether.
That is why this work is still done by hand. There is no single feed to subscribe to, the commercial data providers lag by days, and writing a scraper for one borough teaches you almost nothing about the next one.
So it falls to a person, and it degrades in the predictable way: the boroughs that matter most get checked daily, the rest get checked when there is time, and nobody can tell you which applications were missed.
This is not a proposal. It is a system that has been running in production since February 2026, collecting London planning applications every night for a property business.
Figures are read from the production system, not estimated. Where something has not been measured, this site says so rather than filling the gap. How we count · All case studies →
The same shape, pointed at the boroughs, regions or application types your pipeline actually depends on.
Collection across every authority you need, whatever portal software each one runs.
A nightly run that captures new applications as councils publish them, with agent and applicant details attached where the portal exposes them.
Documents and drawings pulled down automatically where they are available.
Coverage monitoring that can tell the difference between a council publishing nothing and a failure to capture it — and alerts you on the second.
The data in your own database, with an API or a daily report, so it feeds whatever you already use.
All 33 London boroughs are already covered in the production system, bar one that blocks automated access entirely. Outside London, most authorities run one of the same handful of portal platforms, so the work is usually configuration rather than a new build. Tell me which authorities matter and I will confirm before quoting.
A 24-hour refresh cycle. Applications are captured as councils publish them, which in practice means you see an application the morning after it appears on the portal — ahead of the commercial data resellers, who batch.
Planning applications are public records that councils are required to publish, and the registers are designed to be read. The system collects what is published, at a polite request rate, and keeps a record of where every field came from. It does not attempt to access anything behind a login, and it respects authorities that decline automated access — one London borough is excluded for exactly that reason.
It happens regularly, and it is the main ongoing cost of a system like this. The production build handles it with monitoring that flags a borough going quiet rather than assuming there was nothing to collect — a scraper that silently reports success is worse than one that crashes. Ongoing maintenance is quoted separately and openly.
Yes. The data lands in your database and the code is yours. There is no per-record fee and no platform you are locked into.
That depends entirely on how many authorities and how many portal platforms are involved — a single-platform region is a short build, a full multi-platform region is not. You get a fixed price and a date before anything starts.
Tell me which authorities you need and what you do with the data once you have it. If this is not the right fit I will say so on the call rather than send a proposal.