Vepler logo
v2.137.0

Property transactions API, opt-in planning extractions, and richer air-quality responses

New property transactions endpoints, opt-in structured planning extractions via the include parameter, and added air-quality fields for the nearest monitoring station and regulatory-zone charges.

Added

  • New property transactions product. Search standardised completed sales and lease grants with POST /v1/transactions/query, fetch a single record by its opaque composite id with GET /v1/transactions/{id}, or list a property's transactions with GET /v1/transactions/by-uprn/{uprn}. Results are cursor-paginated; all monetary values are in minor currency units (e.g. pence for GBP).
  • The query endpoint accepts a structured query filter (operators eq, ne, gt, gte, lt, lte, in, nin over fields such as kind, tenure, propertyType, price.amount and date), geographic area filters (postcode, outcode, point, polygon), sort, sparse fieldsets via attributes, and limit/cursor pagination.
  • Each transaction reports kind (sale or lease_grant), price, date, tenure, propertyType, a structured address, a lease sub-object on lease grants, and a location block with the matched uprn and point where resolved.
  • Air-quality responses now include a nearestStation field — the nearest active Defra UK-AIR monitoring station (siteCode, siteName, environmentType, distance and bearing) as reference/provenance context, not the source of reported concentrations. Returned on both GET /v1/air-quality/point and POST /v1/air-quality/query.
  • Air-quality regulatoryZones can now carry a charges schedule for charging schemes — a year, a model of daily or penalty, and per-vehicle-class rates with vehicleClass, chargeGbp and complianceStandard. Absent for non-charging designations.
  • Added scoringContractVersion to the air-quality provenance envelope so consumers can detect a scoring-table mismatch between the /point and /query surfaces.

Changed

  • Planning applications can now return structured, citation-backed extractions on request. Pass ?include=extractions on GET /v1/planning/{applicationIds} and GET /v1/planning/sources/{sourceIds}, or include: ["extractions"] in the body of POST /v1/planning/query, to attach an extractions object to each application.
  • The extractions object covers the decision outcome and refusal reasons, development specifics, s106 obligations, the officerAssessment and consulteeResponses, with a coverage report and per-extraction verification status. It is omitted entirely unless requested, so existing responses are unchanged.

Affected endpoints

← All changes