What changed in the API, newest first — and how we handle change.
Building something and want a heads-up on changes, or a field you need? Get in touch.
You can now pass ?council=Cambridge (or kensington-and-chelsea) instead of looking up a UUID or GSS code; an unknown name returns a 404 that suggests the closest matches, never an unfiltered nationwide result. Related: a query parameter we do not recognise has always been dropped silently, which meant a misspelt filter quietly returned everything. Those requests now carry an X-PlanNexus-Ignored-Params header naming what was dropped, and from 1 October they will be refused with a 400 instead. If you see that header on a live integration, the filter is not doing what you think.
Starter can now be tried for 14 days before it bills: card required at checkout, £99/month from day 15 unless cancelled, once per account. The trial has Starter's features — live, nationwide search, contacts, exports, the scorecards — with a 5,000 search-row budget for the fortnight, which is plenty to verify freshness and coverage. Start it from Dashboard → Billing or the pricing page; the billing page shows the end date.
List results from a free or Alerts Pro API key (GET /v1/applications and /nearby) now include only applications PlanNexus first recorded at least 7 days earlier; meta.notice and the X-PlanNexus-Data-Delay: 7d header say so on every such response, and detail by id is unaffected. Together with this morning's scoping rule this makes the free key a genuine sandbox: the full record shape, real data, every filter, and nothing a leads business can resell. Live data is Starter, or the new 14-day trial. Alerts Pro is the alerts product and carries the same API sandbox. Website sessions and every paid tier are unchanged.
GET /v1/applications from a free API key must now be scoped: up to 5 councils (authority_gss), up to 10 postcode districts (postcode), or lat/lng with a radius of at most 25 km. An unscoped request returns 403 with a message saying which bound it broke; GET /v1/applications/nearby caps a free key's radius at 25 km; a saved_search_id feed carries its own scope and is unaffected. Signed-in sessions on the website and every paid tier are unchanged — nationwide search is part of Starter (£99/month). This closes the last way to page the whole live feed for free, and it matches the same-day change to free alerts.
Free accounts now get 3 saved searches, delivered weekly, each scoped to a council, a postcode or a radius up to 25 km (up to 5 councils or 10 postcode districts). Daily delivery, nationwide searches and up to 50 saved searches are part of Alerts Pro (£19/month), alongside the contacts, CSV export and council scorecards it already carried. Searches created on free accounts before 6 September keep running exactly as they were until 6 October 2026, with a notice in each digest, so nobody loses an alert without a month's warning. Creating a new free search that is daily or unscoped is refused with a message saying why; PATCH cannot move a free search to daily. Saved-search responses gain a policy field stating what the plan does to that search right now. Paid tiers are unchanged.
Council enforcement registers as an API: alleged breaches under investigation, with the council's reference, site address, what is alleged, status, the date opened and the date a formal notice was served. GET /v1/enforcement lists cases newest first with filters for council, district-aware postcode prefix, status, opened-date window, notice served and keyword, and states its coverage in every response — about half of idox councils publish no register through their portal, so a council's absence is never evidence of no enforcement. GET /v1/analytics/enforcement/{gss} (paid) gives one council's cases by month, notices served, status mix and the most recent cases, and the same appears as an Enforcement section on the council scorecard. Saved searches gain include_enforcement: opt in and new cases within the search's councils and postcodes arrive in the same digest as applications. The register is read weekly. Additive.
Free accounts previously had no row limit on GET /v1/applications — only the 1,000 request/month quota. They now draw against a 10,000 search-row monthly allowance, the same meter paid plans already use, and receive a 429 with a clear message at the ceiling. Ten thousand rows is a hundred full pages: ample for evaluating the API, and it does not change anything for Starter (50,000), Pro (250,000) or Enterprise (unlimited). Separately, API database queries now carry a 120-second ceiling so no single request can hold a connection indefinitely; nothing legitimate comes close.
Every postcode filter (postcode= on search, export and stats; postcode/postcodes on saved searches; filter_postcodes on webhook subscriptions) applied the prefix literally, so E1 also returned E10–E18, SW1 swallowed SW10–SW20 and SE1 the whole of SE10–SE28 — the docs promised district semantics the code did not deliver. A whole outward code now means that district only, including its lettered sub-districts (E1 covers E1W; SW1 covers SW1A–SW1Y). A bare area (SW) or a longer prefix (SW1A 1, a full postcode) behaves exactly as before. If you relied on the old over-match, pass the neighbouring districts explicitly.
The last three datasets that were reachable only inside a report. /v1/price-paid returns individual HM Land Registry sales at a postcode or outward code (price, date, address, type, tenure, new build, category; filters and a look-back window). /v1/parcels returns the INSPIRE parcel under a point and the parcels touching it as GeoJSON with ids and areas. /v1/epc/{uprn} returns the latest certificate at a UPRN with tenure and its MEES status, addresses never served, suppressions honoured. All open to any signed-in caller on the ordinary request quota. Additive.
GET /v1/analytics/councils/{gss}/pressure-teaser (public) returns the development-pressure grid in five quantile bands and nothing else per cell; it renders on /leagues/planning/{gss} for tracked councils. GET /v1/analytics/energy/{gss}/hex (paid) places every rated EPC certificate on the same grid through its UPRN, with private-rented below-C and F/G shares where a cell has 30 or more — the MEES exposure map on the scorecard, with the cells holding the most private-rented sub-C stock ranked and linked to a search of the applications inside them. Additive.
Tenure was in the bulk file all along and had been kept on every certificate; it is now aggregated. /v1/analytics/energy/{gss} gains private_rented (certificates, rated, F/G and below-C counts and shares, share of stock) with the national comparison and tenure_known_share; the EPC panel on an application shows the certificate's tenure. Also fixed: the bulk EPC file was loaded once and never again — a monthly top-up now upserts certificates lodged since our watermark with every field the file carries (the search-API rows are band-only). Additive.
f_or_g, below_c, pct_f_or_g, pct_below_c and national_pct_f_or_g: certificates rated F or G (cannot be let under MEES without an exemption) and everything below C (the proposed rental standard), per council with the national comparison. Honest scope: certificates, not homes, and all tenures — the EPC register we hold carries no tenure field, so this is the whole stock, not private-rented stock. Additive.
A hex grid over each tracked council shaded by applications received in the last 12 months, with each cell's approval record over 24 months (withheld under 10 determinations) and the brownfield-register sites inside it, plus ranked hotspots that link to a search of the applications in the cell and a concentration figure (share of activity in the busiest tenth of cells). Paid; on the council scorecard under Development pressure. The leaderboard pages (decisions, activity, appeals, agents) were also rebuilt with KPI tiles, distribution histograms, top-N bars and region filters.
GET /v1/applications gains date_decided_from / date_decided_to and sort=decision_date, so decision= plus a constraint filter is a precedent query — rendered at /precedent (free to search). Fixed alongside: a keyword search that also carried a date filter was answered by the full-text index, which silently ignored the date; date-filtered and decision-date-sorted searches now run on Postgres, and the full-text path applies decision= itself. Every application page shows the decision outlook for applications like it at that council, with this case's own clock on the same day axis. /v1/analytics/agents rows carry determined, approved and approval_rate (withheld under 10 determinations); the agents leaderboard ranks by volume or approval rate. Additive.
Returns the all-types answer plus every application type with its own sample (approval rate over determinations, median and 90th-percentile decision days, comparable count, confidence), largest first. A type with fewer than 30 comparable determinations comes back as insufficient with its count rather than being widened to the council. One grouped query where the scorecard previously made thirteen calls. /v1/outlook and /v1/applications/{id}/outlook are unchanged. Additive.
The paid scorecard at /dashboard/analytics/{gss} is a report rather than a set of sparklines: quarterly approval and timeliness against the national line with decisions per quarter beneath, a decision-outlook table by application type against the 8- and 13-week periods (previously API-only), monthly submissions with a 12-month average, ranked agent and appeal-agent bars, overturn by procedure, the market by year and the EPC profile — every chart with axes, gridlines, legends, direct labels, a hover crosshair, keyboard navigation and a table view. An 'In brief' read-out at the top is derived only from figures on the page. Section navigation and print support. Page load for a large council fell from ~13s to ~6s after a partial index on decisions and a single grouped outlook query. What it shows is described publicly at /analytics.
A worklist of the applications you have not written to yet (scoped to a saved search, a council, or a radius, minus anything already written to, dismissed, or on your do-not-write list), campaigns with one row per envelope, per-letter edit and PDF preview, your letterheads and standard letters with merge fields, and sending through your own Stannp, Docmail, Intelliprint, PostGrid or ClickSend account — your credentials, encrypted, your postage. Included in Starter and above; each letter sent draws one export row, nothing is charged per letter. Under /v1/letters/* (worklist, campaigns, providers, letterheads, templates, suppressions, dismissals, merge-fields); the merge-ready CSV at /v1/applications/letters.csv stays on every paid plan. Note: that CSV endpoint had been unreachable since it shipped on 28 Aug because of route ordering — fixed today.
The party-wall question, answered from data we may redistribute: the HM Land Registry INSPIRE parcel containing a point, every parcel touching it, the OS Open UPRNs inside them with an ONS postcode each, and an address wherever a council-published register or gazetteer names the UPRN. EPC addresses are never used and nothing touches AddressBase, so the response counts named against unnamed rather than hiding the gap — statutory-notice certainty still needs a licensed address product. Starter and above, one lookup per call against a monthly allowance.
GET /v1/ownership (4.6M corporate and overseas Land Registry titles by postcode or district — company ownership only; an absent title means not corporately held, never unowned). GET /v1/obligations (Section 106 covenants and CIL liabilities from the councils publishing an Exacom register — nine today, twenty-five more being walked; coverage is stated per response). GET /v1/brownfield (the national union of councils' brownfield land registers, open data, any signed-in caller). GET /v1/uprn/{uprn} (the OS Open UPRN point, its ONS postcode, any council-published address, and the applications we hold at it). GET /v1/addresses (addresses with UPRNs for a postcode from the council gazetteers we hold — not a national address product). All additive.
A public page for every English planning authority with current PS2 returns (310 today) at /leagues/planning/{gss}: the rolling-year approval rate, refusal rate and share decided on time against the national figure, the major / minor / householder split, and a calendar-year history back to 1979 with partial years marked — official MHCLG PS2 returns, no modelling. The quarterly series and regional comparisons remain on the paid scorecard.
GET /v1/outlook and /v1/applications/{id}/outlook answer 'will this be approved, and when' from 1.28M decided applications across 347 authorities: approval rate over determinations, median and 90th-percentile decision days, and the number of comparables behind the figure. No rate is returned below 30 comparables; the query widens to the council and says so. Free on every tier. Enforcement registers are now ingested from the Idox councils that publish them (about half do) into their own table; coverage is stated per council.
Until now, JSON search-result rows and CSV-export rows drew down one shared monthly pot, even though our published limits only ever described export. That conflated two very different things: search rows are summaries without contact fields, while CSV rows carry the full record including contacts. From today they meter separately. Starter's search allowance rises to 50,000 rows/month (measured real integration usage runs 30-35k — the old shared 10,000 was set against CSV-export statistics only, and we're correcting the 31 July note's claim that it comfortably exceeded real usage: measured on the counter that actually enforces it, it didn't). CSV export stays at 10,000 rows/month on Starter and Alerts Pro exactly as published, and Data Feed carries 250,000 on both meters. Your usage page now shows both meters, and the usage API gains list_rows_this_month and monthly_list_row_ceiling (additive). Nobody's allowance went down.
Three new GeoJSON layers alongside /v1/geo/flood-zones, same conventions (bbox area cap with 413, simplification, attribution array, explicit truncated flag). GET /v1/geo/flood-defences?bbox= serves Environment Agency AIMS defence assets as lines — walls, embankments, natural high ground — with type, protection_type, design_sop / current_sop (the standard of protection in the EA's own units; current_sop is often null because the register is honest about unassessed assets), condition, maintainer and watercourse. Defence lines, deliberately not defended areas: the EA's Areas Benefiting from Defences product is retired and its successor is mid-supersession, so we serve what physically exists without claiming which land it protects. GET /v1/geo/historic-floods?bbox= serves Recorded Flood Outlines — floods that actually happened, with per-event start_date / end_date, source, and hfm_status showing whether the EA accepted each outline into their merged Historic Flood Map. Observed history and modelled zones are different statements about risk; now the API can make both. GET /v1/geo/water-structures?bbox= serves the register's structures — weirs, sluices, control gates, outfalls, breakwaters and groynes — mixed Point and MultiLineString geometry (a source artefact of one asset class; handle both), with kind, type, name where the register holds one, and the same standard-of-protection fields. All three refresh quarterly from source.
The account endpoint now returns entitlements — the named product surfaces the account may open, e.g. ["map"]. Check this rather than matching on the tier name: packaging changes on our side, and anything that hardcodes "pro and above" drifts the moment it does. An empty list means no gated surfaces. Additive, so existing clients are unaffected.
Three new GeoJSON endpoints for map layers: GET /v1/geo/flood-zones?bbox= (Environment Agency zones 2 and 3, clipped to the bbox and simplified), GET /v1/geo/listed-buildings?bbox= (National Heritage List points with name, grade and list entry) and GET /v1/geo/lpa-boundary?gss= (a single authority outline). Each response carries its Open Government Licence attribution so consumers can render it without hunting for the wording. Bounding boxes are area-capped at 0.5 deg² and refused with 413 rather than quietly trimmed — a silently shrunk bbox would draw a map that looks complete and isn't; feature counts carry an explicit truncated flag for the same reason. Two response shapes worth knowing before you build against them: lpa-boundary returns a bare Feature rather than a FeatureCollection (it answers "the boundary of this authority", which can only ever have one member), and listed-buildings returns MultiPoint and Polygon geometries rather than Point — that is how the National Heritage List stores them, and collapsing a listed curtilage to a single marker would misstate its extent. Registered land parcels are not served as a layer and won't be: they stay within the existing narrow plot-picker window.
parent_reference and parent_application_id now appear on search results, not just application detail — so stalled-consent and start-imminent views can be built from one search call instead of one detail call per row. Alongside them, geocode_precision states how each coordinate was derived: portal (the register published a position), postcode (unit centroid, ~100m), street (the address matched to a road — median 40m, p90 500m), or null for older rows of unknown provenance. Anything drawing a pin at street zoom should treat street and null as approximate. Both fields are additive.
Machine consumption of the dataset — incremental sync via changed_since and webhook push — is now part of the Data Feed plan (£399/mo, replacing Pro at the same internal tier). Interactive use is unchanged on every plan: search, detail, spatial queries, alerts, analytics, and CSV export (Starter/Alerts Pro export now meters at 10,000 rows/mo — several times the heaviest real usage we have ever seen on those plans; Data Feed carries 250,000). Until 1 September 2026, changed_since calls from other plans continue to work and return a Deprecation header; from that date they require the Data Feed plan. Webhook creation requires Data Feed immediately (no existing subscriptions were affected). Every affected API key holder has been emailed. Self-serve plans are licensed for internal business use — redistributing bulk data or operating a data service on top requires a commercial licence.
Discharge-of-conditions and variation-of-condition applications now carry parent_reference (the permission their description cites, normalised) and parent_application_id (the same-authority application it resolves to) on the detail endpoint. Additive — null where no citation exists or the parent isn't captured. This is the join that turns condition activity into site signals: what's moving toward a start, what's stalled.
One call, everything we hold about a site: planning history and outcomes, live constraints, flood zone, LPA performance, appeals, heritage, market context, EPC where present, and area ownership statistics. Every layer carries its own provenance and degrades honestly; the dossier states its own outcome-coverage grade. Locate by postcode, coordinates, UPRN or address. Metered per tier (Free 25 / Starter 250 / Pro 1,500 lookups per month; Enterprise unlimited). Also available as the get_property_dossier tool on the hosted MCP server and in both SDKs.
Section 73 (England & Wales) and Section 42 (Scotland) variation-of-condition applications — including minor material amendments — now carry their own application_type, variation_conditions, instead of being mixed into discharge_conditions or coarser buckets. Additive: no existing type values were renamed. Historical records have been re-derived, so type filters return cleaner sets — most visibly in Glasgow, where a reference-suffix quirk had over-counted discharge_conditions.
Where a property has an EPC, the application detail endpoint now includes it: rating band, efficiency scores, floor area and CO₂ figures, matched by the property reference number (UPRN) and served to all tiers under the Open Government Licence with attribution carried on the object. Additive — the epc field is null where no certificate matches. Property owners can ask us to stop showing their EPC (see the privacy policy §3a); suppressed properties return epc: null.
Application responses (GET /v1/applications and the detail endpoint) now include a parsed breakdown of the site address alongside the existing address string: address_line1, address_town, address_county and address_confidence ("high" | "low"). Parsed with libpostal from the public-register address — no new gating (free and paid both receive it), and address remains the authoritative source. Additive: the fields are null where an address hasn't been parsed yet, so existing clients are unaffected.
The /site-appraisal page now lets you tap your exact plot on an interactive map before buying — the deep report then identifies your registered land parcel (highlighted against its neighbours) instead of the postcode-level parcel pattern. Powered by a new open endpoint, GET /v1/reports/parcels?lat=&lng=, returning nearby HM Land Registry INSPIRE parcel boundaries as GeoJSON. Report checkout accepts lat & lng alongside postcode.
The £99 deep report (via /v1/reports/*) now opens with an indicative planning verdict and an at-a-glance scorecard, draws your registered land-parcel boundary (HM Land Registry INSPIRE) on the location map with a plot close-up, and point-checks the site against national datasets: the precise EA flood zone the site sits in, listed buildings named with grade and distance, scheduled monuments, the Brownfield Land Register, recent sales at the site's postcode and district-level corporate ownership. Maps are rendered from OS Open Zoomstack (OGL) served in-house.
Every constraint in constraints.summary is now the same object shape — { present, label, count } — where present is a boolean, label is the headline name/grade/level (or null), and count is the number of overlapping entities. Previously a value could be a string, a boolean, an integer or null depending on the constraint, which couldn't be modelled in a typed client. The full per-entity data in constraints.details is unchanged. This in-place reshape is the change that prompted the policy above; from here, changes like it are made additively.
The benchmarking leaderboards under /v1/analytics/* — appeals overturn rates, energy efficiency, property market and planning timeliness — no longer require an API key.
Agent, applicant and case-officer details on the application detail endpoint are available on paid tiers. Free responses include a redacted_fields list naming exactly what is withheld, so you always know what a paid key would add — no field silently disappears.