One API key replaces a dozen government data integrations. LSOA-grain signals across seven categories with country-scoped percentiles, per-signal confidence, and source attribution on every response. Built for portals, valuation tools, agent CRMs, and search products.
A user on your property detail page has already decided they care about this address. The next thing they want to know is what the area is like. Schools. Crime. Prices in the neighbourhood. How it compares to other areas they have looked at. How it has moved over the last year.
Building that view yourself means integrating the police bulk archive, HM Land Registry Price Paid, the IMD / WIMD / SIMD deprivation indices, Ofsted, ONS NSPL for postcode resolution, OpenStreetMap for amenity counts, and the Environment Agency for flood. Then normalising mismatched deciles, reconciling 2011 versus 2021 boundaries, deciding what to do when Scotland prices fall back to live because HM Land Registry is England and Wales only. Then owning the refresh cadence forever.
That is a data team. Most PropTech teams already know they should not be hiring one. The question is what to integrate against instead.
What a typical PropTech integration actually looks like. No magic. One Bearer token, plain JSON, paths under /v1/.
Drop GET /v1/area into your property detail render. We resolve the postcode to its LSOA via the ONS spine and return the seven-category catalog. No 12-step join across upstream APIs.
GET /v1/area?postcode=M1 1AE -H "Authorization: Bearer oga_..."
Each signal carries value, normalized_value, percentile (national within country), direction, source, observed_period and confidence. Render whichever fields fit the panel. Percentile bars work especially well.
{
"key": "crime.total_12m",
"value": 3712,
"percentile": 92.1,
"confidence": 0.9,
"direction": "lower_is_better"
}If you want a single number per listing for your search filters or summary card, POST /v1/score with one of four scoring profiles. Deterministic engine, version stamped on every response, same input always returns the same number so cached UI states stay coherent.
POST /v1/score
{ "area": "M1 1AE", "preset": "moving" }
-> { "score": 58, "engine_version": "2.0.2" }POST /v1/peers gives you the k-nearest LSOAs by Euclidean distance over normalized signal values. Powers an areas-like-this-one widget without you running a peer graph cache.
POST /v1/peers
{ "target": { "postcode": "M1 1AE" },
"country": "England", "k": 20 }Bearer token authentication, plain JSON over HTTPS, all paths under /v1/. No SDK required. 30 requests per minute per key on every product surface; cached responses do not count against quota.
# That is it. A handful of curl-equivalent calls. # Bearer header, JSON body, /v1/ paths.
Monitor (portfolios plus change detection) is not the primary lift for PropTech, but Signals, Scores, and Intelligence cover every area-context surface a property product needs.
The primary integration for PropTech. GET /v1/area returns the seven-category catalog at LSOA grain. Pin to the signal keys your product consumes (property.median_price, crime.total_12m, deprivation.imd_decile, transport.station_count) and the contract stays additive over time.
GET /v1/area?postcode=SW1A 1AA
{
"geo": { "lsoa": "E01000001", "country": "England" },
"signals": [ { "key": "...", "value": ..., "percentile": ... } ],
"meta": { "engine_version": "2.0.2", "fetch_mode": "hybrid" }
}When your UI needs a single 0-to-100 number per listing for search filters or a summary card. Four scoring profiles cover the four audiences your product sees (residential origination, commercial, investment, research baseline). Components plus weights plus confidence come back in every response so you can drill into the breakdown on demand.
POST /v1/score
{ "area": "SW1A 1AA", "preset": "investing" }
-> { "score": 71, "area_type": "urban",
"dimensions": [...], "engine_version": "2.0.2" }When you want a similar-areas tile or natural-language area search baked into your product. POST /v1/peers powers areas-like-this-one in one call. POST /v1/query accepts free-text questions or programmatic plans and returns ranked results from deterministic SQL.
POST /v1/query
{ "question": "cheap places to buy with rising prices and low crime" }
-> { "plan": { "op": "rank_areas", ... },
"plan_source": "nl",
"results": [ ... ] }None of these are unique pitches per ICP — they hold across the platform — but they matter for PropTech because your end users ask questions about every number you show.
engine_version is stamped on the body and on the X-Engine-Version response header. If a score in your UI gets challenged, you can point at the exact methodology version that produced it.
Percentiles are national-within-country. England's IMD, Wales's WIMD, and Scotland's SIMD are different methodologies. We refuse to manufacture a cross-border percentile that would be a lie.
Every signal carries source, observed_period, confidence, and a plain-language confidence_reason. fetch_mode is honestly live, store, or hybrid so you always know how each value was served.
Same postcode plus same scoring profile equals the same score across deploys. Cached UI states stay coherent. The engine is frozen v2 and golden-tested; AI never sets the numbers.
Bearer-token API at /v1/area is rate-limited at 30 requests per minute per key. For higher-throughput listing-page traffic the typical pattern is to cache the AreaProfile per postcode at your edge and serve the JSON yourself. Same postcode within a month is deterministic, so cache windows can be generous.
LSOA × month. There are about 42,000 LSOAs across England, Wales, and Scotland; postcodes resolve into LSOAs via the ONS NSPL spine. We do not offer per-postcode or per-address signals today; address-level (UPRN) is on the roadmap.
Attribution is on you. Each signal carries a source string (e.g. police.uk, IMD 2025) so you can render it next to the value if your platform needs to. The OneGoodArea brand is not required on your listing pages unless your contract says so.
fetch_mode is honestly hybrid. Deprivation comes from SIMD (Scotland's index), crime from police.uk, transport and amenities from OpenStreetMap. Property median price falls back to live fetch because HM Land Registry covers England and Wales only. Your UI gets the value with a confidence dot reflecting that source.
We are early. We would rather have a clean published methodology and a stamped engine version on every response than logos that imply social proof we have not earned. If procurement needs deeper assurance we are happy to do a call.
Pricing is being finalised. The /v1/area endpoint is the primary read for PropTech and is rate-limited rather than monthly-quota-metered, which makes integration testing cheap. Get an API key and use it; we will tell you ahead of any price changes.
One endpoint, one API key, one engine version stamped on every response. Drop /v1/area into your listing pages and replace a dozen data integrations.