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 stitching together a few councils manually 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 build direct council-portal integrations 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 response shape across supported councils. Check coverage for your area, then query by council, postcode or free text:
curl "https://api.planwire.io/v1/applications?postcode_prefix=BS1&date_from=2026-05-01&limit=5" \ -H "X-API-Key: your_api_key"
For a reproducible first request, follow the Node.js planning API integration walkthrough and run the dependency-free search example on GitHub. The PlanWire reference handles empty responses and errors and keeps the key server-side. It is not a customer case study.
For ongoing updates, use the webhook delivery and recovery guide alongside the application field reference. Verify coverage and source freshness for your users' councils before treating the prototype as production-ready.
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 portal-maintenance 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 the portal-maintenance work you'd otherwise staff.