How to Choose a UK Planning Data API: A Build-vs-Buy Guide for PropTech Teams

Why this guide exists

Every PropTech team eventually needs UK planning data. Property platforms want to show what's being built nearby. Valuation tools want approval rates as an AVM signal. Insurance underwriters want to flag refused applications on a property's history. Trade-services products want leads — homeowners with approved extensions. Lead-gen tools want refused applicants pivoting to a different route. The list is long, the use cases are real, and the data is technically public.

The catch: there are 382 local planning authorities in the UK, split across many portal vendors, hosted systems and older bespoke registers. Every source has different search fields, different decision wording, different freshness, different access patterns and different ways of breaking.

So your team has three options: build it (own the treadmill), buy it (rent a normalised feed), or punt on national coverage and integrate council-by-council as customers demand. This guide is about how to make that decision — and if you decide to buy, the seven questions that separate a real provider from a demo.

The three honest options

Option 1 — Build it yourself

This is the path most engineering-led PropTech teams default to. The first few councils are tractable: pick the biggest authorities, wire up a proof of concept, ship a v1. The trap is that a small working sample gives you the impression you've solved the problem. You haven't. National coverage is the problem.

What "building it" actually requires at scale, based on what we've seen running it in production:

• Multiple source adapters for different portal families, hosted variants, legacy systems and council-specific templates.
• A resilient rendering and access layer for sources that behave differently depending on sessions, browser state, JavaScript rendering or worker location.
• Source-migration tracking so old domains, historic registers and moved search forms do not silently become stale data in your product.
• A normalisation layer that turns inconsistent application types, statuses and decision text into a stable schema your product can trust.
• Decision-outcome classification so approvals, refusals, withdrawals, split decisions and edge cases do not collapse into raw text.
• A health and freshness monitor for every source, so your team knows when coverage is current, stale, blocked or genuinely unavailable.
• An operations loop for fixing sources as councils change systems, publish malformed rows, or alter their public register behaviour.

Realistic build cost: 2-3 engineers full-time for 6-9 months to hit credible national coverage, then 0.5-1 engineer ongoing to keep it alive. At loaded UK PropTech rates that's roughly £200k-£400k to get to v1 and £80k-£120k/year to maintain it. The maintenance number is the one most teams under-estimate by 5x.

Option 2 — Buy a planning data API

You pay a few hundred to a few thousand pounds a month, you get one schema across every authority, somebody else owns the scraper farm. Your engineering team spends their time on your differentiated product instead of on brittle portal access and rendering work. Capable providers handle the source access layer, the migrations, the normalisation and the freshness monitoring for you.

Realistic buy cost: £30-£600/month for development-grade tiers, £500-£3000/month for production volumes with webhooks and SLAs. Even at the top of that range, twelve months is cheaper than one engineer's salary, and you ship in days not quarters.

Option 3 — Don't aim for national coverage

Underrated option for some products. If your customers are concentrated in a few cities, you can integrate three or four council portals directly and skip the rest. The math changes completely: one or two scrapers, no normalisation problem, no national health monitor. The risk is that the moment you sign a customer outside your covered councils, you have a much bigger product gap than you expected — and you've been quietly limiting your market without realising it.

If you're buying — the seven questions

Most planning data API demos look identical. They all show a clean curl, a normalised JSON response, a map of councils on a slide. The real differences are in answers that don't fit on a slide. Ask all seven. Anything a provider can't answer specifically is a red flag.

"We cover the whole UK" is the most common claim and the least informative. The honest answer is a list of every local planning authority, marked live or stale, with the last successful scrape per source. The reason this matters is that coverage degrades silently. A council migrates portal vendors, the provider's scraper breaks, but their marketing page still says "300+ councils." The data you're paying for is six months old for those councils and nobody told you.

Ask for a public, machine-readable coverage page — ideally one with a per-council "last refreshed" timestamp. If they have to email it to you, that's a sign nobody owns the freshness number internally. Here's ours as a reference.

"Daily updates" usually means "we run the scraper every day, but if it failed we don't refresh." The question you actually want answered is: for the median council, how many days behind real-time is the typical record? Twenty-four hours is excellent. Three to seven days is fine for most use cases. Thirty days is a problem dressed up as a feature.

Also ask: what happens when a council's portal breaks? Does that source disappear from results, return stale rows silently, or get flagged as "data_stale" so your application can show the right caveat to the user? A provider with no answer here will quietly degrade your product over time.

Submitted applications are the easy half. Decisions — approved, refused, withdrawn, conditions discharged, prior approval not required — are where the value sits for valuations, AVM signals, lead-gen and refusal-history products. Many providers ship decisions as a free-text decision field copied verbatim from the council portal. That's not data; that's a parsing problem you've just bought.

What you want is a normalised decision_outcome enum (we use approved, refused, withdrawn, other, unknown) with a clear classifier behind it that handles vendor abbreviations, conditional grants, split decisions, prior approval refusals, and the dozens of ways "refused" gets written. Ask the provider to explain their classification approach, not just the field name. If they can't explain it, the field is unreliable.

You're integrating this into a database, downstream models, customer-facing features. A schema change is not a release note — it's a production incident. Ask for: the full field reference, the versioning policy (additive only? semver? breaking changes with notice?), and a deprecation example from the last twelve months.

Geo fields matter more than people expect. Latitude/longitude per application is the difference between "we can do radius search around any postcode in seconds" and "we batch-geocode 10 million records ourselves." Confirm geo is included, populated to a sensible coverage percentage (over 90% is fine, under 70% means you're geocoding), and queryable directly.

This is the single best question to find out whether the provider actually runs this in production or runs a sales demo. Council migrations happen monthly across the industry: hosted systems change, vendor contracts move, old domains become historic, and search flows quietly shift underneath the same council name. Every migration breaks the old URL.

A real provider has a documented playbook: how they detect a migration, how fast they reroute, whether the change is transparent to your code (i.e. the council ID stays the same, just the underlying source URL changes), and whether you're notified. A provider without an answer here will hand you a stale council without telling you and you'll find out from a customer complaint.

"We have webhooks" is table-stakes. The questions that matter: delivery guarantees (at-least-once with idempotency keys is the right answer), retry behaviour (exponential backoff with a clear dead-letter window), filter granularity (can you subscribe to "new applications in postcode SW1 matching keyword 'extension'" or do you have to consume the firehose?), and signature verification so you can prove the payload came from the provider.

If a provider only offers polling, that's fine for batch use cases but bad for alerts/lead-gen products where minutes matter. Confirm what your specific product needs before you sign.

"Talk to sales" can be appropriate for genuine enterprise deals but it's also a way to hide that the provider doesn't know what to charge. A real provider has clear tiers published on their website, with rate limits in actual calls/day and webhook caps in deliveries/day. Surprise-pricing on usage spikes is a real risk for an alerts product where one celebrity-postcode listing can 10x your call volume overnight.

Two specific things to confirm before signing: what happens if you exceed your tier (graceful degradation with a notification, or a hard 429 that kills your product?), and whether the provider charges per-API-call or per-application-returned (the latter scales unpredictably; the former is easier to budget).

Red flags worth backing out for

Things that look fine in a demo and end up being load-bearing problems in production:

• "We're built on planning.data.gov.uk" as the primary source. The UK government's open dataset is genuinely useful for slow-moving reference data, but only ~30% of councils publish to it, and the freshness lag is often 60+ days. Anyone whose product is fundamentally a reseller of this feed is selling you a smaller, slower version of free.
• No public coverage page. If a provider won't show you which councils are live today, the number isn't 382.
• No documented webhook signature verification. Means you can't verify payload origin or integrity.
• "We have a custom solution for that council" when you ask about a specific authority. Translation: that council isn't covered today and they'll build something if you sign.
• Decision outcome shipped as raw text. See question 3. You're buying a parsing problem dressed as data.
• No status page or no admitted history of outages. Either they don't run this in production, or they hide incidents from customers. Both bad.

The build math, more carefully

For teams genuinely torn on build-vs-buy, work the numbers honestly. The cost of building is more than the engineer salary; it's the opportunity cost of not building your differentiated product. A small PropTech team has three or four engineering bets it can place per year. Spending one of them on the scraper farm means one less bet on whatever your customers actually pay you for.

A useful test: ask your CTO whether they'd choose to debug a blocked portal session, a browser-rendered result page, and a council source migration — over building the AVM feature your customers are asking for. The answer is almost always no, even when the team thinks they want to build.

The honest exception: if planning data is your product — you're not a PropTech app integrating planning, you're a planning data tool selling raw access — then yes, build it. The treadmill is your business. For everyone else, rent.

What "good" looks like in the contract

If you've decided to buy, make sure these end up in the agreement, not just the sales call:

• Coverage commitment — minimum number of councils marked "live" at any given time, with a remedy if it falls below.
• Freshness SLO — e.g. "95% of records refreshed within 48 hours of the council portal showing them."
• Source-migration notification — if a council moves portals, you're told within N business days.
• Schema change policy — backwards-compatible by default; breaking changes with a documented deprecation window.
• Webhook signature method — HMAC with documented secret rotation procedure.
• Rate limits in writing — both your tier limit and the provider's overall throughput ceiling.
• Data export rights — if you ever leave, you can take your historical data with you in a sane format.

A simple integration to prove the shape

Whoever you pick, the integration should be small. Recent applications in a postcode area, returned as one normalised record per row, ready to ingest:

curl "https://api.planwire.io/v1/applications\
?postcode_prefix=SW1\
&date_from=2026-05-01\
&decision_outcome=approved\
&limit=50" \
  -H "X-API-Key: your_api_key"

Each row has reference, address, postcode, lat/lng, description, application type, status, classified decision outcome, decision date, and a link to the originating council record. Same shape across every authority. If the integration takes more than an afternoon to wire into your product, the provider's API isn't really normalised — they're handing you the cleanup as homework.

The bottom line

Build planning data infrastructure only if planning data is your business. For everyone else — PropTech CTOs, product leads at property platforms, valuation tools, insurance underwriting, due diligence products — the rational move is to buy. The cost is bounded, the time-to-ship is days, and you keep your engineering team on the things that actually differentiate your product.

When you buy, ask the seven questions. Walk past anyone who can't answer them specifically. The right provider has a public coverage page, a classified decision outcome, a documented migration playbook, transparent pricing, and the muscle memory of having actually run this at scale through source changes, council migrations and hard-to-render portals. The wrong provider has a slide deck.

If you're evaluating PlanWire as one of those options, the things we'd point you at first: the live coverage page with per-council freshness, the documented schema including the decision-outcome classifier, and the public pricing. If you want to talk to us about a Growth or Enterprise integration, reply to any email or use the contact path on the pricing page — we'd rather have a 20-minute call than a half-built free-tier integration that doesn't fit.