Docs · Engine v2.0.2

Build on UK area intelligence.

Four composable products on one signal-first data layer. Reach the API directly from your stack, or use the dashboard to configure how the API behaves per organisation. This index points to every reference we publish today; per-surface guides are landing one by one.

01The 4 products

One signal-first data layer. Four composable products.

Each product sits on shared infrastructure and can be consumed in isolation or composed. Per-surface guides land as separate pages over the coming weeks.

§ 01

Signals

The deterministic, addressable UK area-data layer. Every signal is a typed primitive with value, normalised value, national-within-country percentile, source period, and per-signal confidence. LSOA grain, monthly cadence on the dynamic series.

  • Typed Signal primitive (Zod-validated in packages/contracts)
  • Honest provenance via meta.fetch_mode (live, store, hybrid)
  • Append-only monthly time-series, immutable per observed_period
  • Derived signals are first-class store rows (YoY, momentum, slope, peer-relative z)
GET/v1/area
§ 02

Scores

Deterministic composite scoring. Pick one of four presets (moving, business, investing, research), each with its own five dimensions. Override the weights per request, or save a preset against your org. No AI in the scoring path; the engine version is stamped on every response.

  • Four presets, each with a different five-dimension set
  • Custom per-request weights or saved preset_id (per org)
  • Per-dimension confidence plus aggregate confidence
  • engine_version on the body and X-Engine-Version response header
POST/v1/score
§ 03

Monitor

Portfolios plus change detection. Save a book of areas (postcodes or LSOAs), bulk-enrich through the scoring engine, and detect material moves across the time-series. Signed webhook alerts (HMAC-SHA256) when something material shifts.

  • Portfolios as named collections of areas (CRUD, dedup)
  • On-demand period-vs-period change detection
  • Sample-size gated (default min 8 transactions on price moves)
  • Three webhook events: report.created, score.changed, signal.changed
POST/v1/portfolios
§ 04

Intelligence

A typed query plus insight plane over the moat. Six plan ops (rank_areas, get_area, score_area, find_peers, find_insights, find_forecast) reachable as a Zod-strict programmatic plan, or as natural language that the planner translates into the same plan.

  • POST /v1/query with {plan} (programmatic) or {question} (NL)
  • k-NN peers with materialised ~840k-row peer graph
  • Anomaly screening via pre-materialised peer-relative z-scores
  • Linear-regression forecast — not a learned model, not ARIMA, not Prophet
POST/v1/query
02Levers

Multi-tenant control plane. Opt-in, additive.

Eight capabilities for configuring OneGoodArea per organisation. With no bundle, preset_id, pin, cohort or allowlist set, every product endpoint behaves byte-identically to the pre-Levers baseline.

§ 01

Orgs and members

Every account gets a personal org on signup. Add teammates, list members, remove them. Three-tier RBAC: member, admin, owner.

Admin+
§ 02

Custom signal bundles

Named whitelists of signal keys. Pass ?bundle=<id> on /v1/area, /v1/areas, or /v1/query and only those signals come back. LLM-planned queries are governed by the same gate.

Admin+
§ 03

Custom scoring presets

Save a {base_preset, weights} recipe under your org and call /v1/score with preset_id. Mutually exclusive with preset and weights on the same request.

Admin+
§ 04

Methodology pinning

Lock the engine version your org consumes. Sets the X-Engine-Version response header on /v1/area, /v1/areas, /v1/score, /v1/query, /v1/peers, and portfolio enrich and changes.

Owner
§ 05

Peer cohorts

Named lists of LSOA codes (up to 10,000 per cohort) that constrain the candidate set on /v1/peers. Areas like THIS one, but only inside your universe.

Admin+
§ 06

Full RBAC

Three roles. Admin drives day-to-day Levers config. Owner-only retained for methodology pinning, granting owner, and removing owner-role members.

Any member
§ 07

White-label

display_name and brand_url on the org, surfaced on /v1/me so downstream consumers can render your brand instead of OneGoodArea’s.

Admin+
§ 08

Per-key IP allowlist

allowed_ip_cidrs on each API key. Mismatch returns 403 ip_not_allowed, distinct from a 401 invalid-key. IPv4 CIDR matching with hand-rolled integer-mask helper.

Owner
04Quickstart

Three steps from zero to your first signal read.

The fastest way to feel the API: one read against /v1/area to see a full area profile with normalised values and provenance.

Step 01

Get a key

Sign up. A personal org and an API key are created for you. The key is prefixed oga_ and shown once at creation time.

Step 02

Send a request

Bearer auth, JSON over HTTPS, all routes under /v1/. The simplest read is GET /v1/area with a postcode query parameter.

Step 03

Read the response

Every payload carries an engine_version, source provenance, and a meta.fetch_mode (live, store, hybrid) so you always know how a signal was served.

GET /v1/areabash
01curl https://api.onegoodarea.com/v1/area?postcode=SW1A%201AA \
02 -H "Authorization: Bearer oga_your_api_key"
05Code examples

One endpoint, four languages.

Every example reads the same area profile. Swap the postcode, swap the surface, swap the language — the shape is the same. No SDK is required, no client library is shipped today.

cURLPlain HTTP rejected. HTTPS only. JSON over the wire.
GET /v1/areabash
01curl https://api.onegoodarea.com/v1/area?postcode=SW1A%201AA \
02 -H "Authorization: Bearer oga_your_api_key" \
03 -H "Accept: application/json"

Build on the data layer underneath UK property workflows.

Generate a key, integrate against the API, and configure how it behaves per organisation through the dashboard. Per-surface guides are coming; everything live is linked above.