The opportunity hiding in the mess
Planning data is public, valuable, and genuinely hard to aggregate. Every UK local planning authority runs its own portal — Idox, Northgate, Ocella, Tascomi and more — each with different search, different fields, and different ways of wording the same outcome. Most teams that need it end up either scraping a few councils badly or buying stale exports. The teams that get clean, normalised, national planning data can build things the rest can't.
What you can build on it
- Alerts & monitoring — notify users of new applications near their property, street, or portfolio.
- Valuation & AVM signals — feed nearby development, approvals and refusals into pricing models.
- Lead generation — surface homeowners with approved extensions for trades, or refused applicants for buyers.
- Due diligence — attach full planning history and decision outcomes to a property record.
- Site sourcing — find development opportunities from lapsing permissions and refusals.
The build-vs-buy reality
You can scrape council portals yourself. But you'll spend your engineering time chasing portal changes, Cloudflare challenges, source migrations and the endless variety of how councils record decisions — not on your actual product. The whole point of a planning data API is that someone else owns that treadmill, and you get one consistent schema across every authority. Build the differentiated thing; rent the plumbing.
The integration
One endpoint, one shape, every council. Query by council, postcode, area or free text:
curl "https://api.planwire.io/v1/applications\ ?postcode_prefix=BS1\ &date_from=2026-05-01\ &limit=50" \ -H "X-API-Key: your_api_key"
Each application returns a normalised record: reference, address, postcode, coordinates, description, application type, status, decision outcome and decision date, plus a link to the source council record. Geo fields make it trivial to map or do radius queries; the consistent decision field means you don't write 12 different parsers for "approved." For production, webhooks push new matching applications to your backend so your product stays live without a scraping team behind it.
The hard part of planning data isn't the API call — it's normalising 300+ portals and the dozens of ways councils word an outcome into one clean schema. That's the part you don't want to own.
From prototype to production
A prototype can run on a free preview. Production needs three things a serious data layer must have: coverage (does it actually cover your users' areas — check the coverage map), reliability (consistent uptime and refresh), and throughput (volume + webhooks for real usage). That's the line where teams move from tinkering to building a business on the data — and it's exactly where a proper plan pays for itself many times over versus a scraping team you'd otherwise hire.