What OneGoodArea stores when you call the API, for how long, who can read it, and how to opt out.
OneGoodArea processes area-level statistical data only. All signals are aggregated to small-area geographies (LSOA in England and Wales, Data Zone in Scotland), typically around 1,500 residents. We do not collect, store, or process personal data about individuals in our signal store, and no output can identify a person, household, or property.
We log structured metadata for every authenticated API call. This is the only thing we capture by default:
event name (e.g. api.score.computed, api.query.executed)user_id + org_id (you, your organization)created_at (timestamp)metadata JSON describing the call shape: area, preset, op (for /v1/query), counts, the computed score number. No raw response body, no chat content.source ("mcp" or "api") and client_app ("claude-desktop", "cursor", "claude-code", "other"), derived from the User-Agent header. We use this to understand which integrations are used.We do NOT log:
/v1/score?explain=true (unless you participate in training, see below)/v1/query (unless you participate in training, see below)Retention: indefinite. This is operational data we need to bill, debug, and answer support questions.
We capture two additional kinds of data to train smaller proprietary models that, over time, replace third-party LLM calls inside our infrastructure. You can opt out per API key at any time (see below).
When you call /v1/query with a natural-language question (for example find_areas via MCP), we store:
source and client_appWe do NOT log the response body, only the emitted plan. Programmatic /v1/query calls that supply their own plan are not logged; there is no training value in them.
Purpose: train a smaller model to translate natural-language area questions into typed plans, so we depend less on a third-party LLM per request.
Storage: a dedicated store, kept separate from operational logs. Internal access is restricted, and our admin tooling shows aggregate counts only, never the raw question text.
When you call /v1/score?explain=true (for example score_postcode via MCP), we store:
source and client_appWe do NOT log calls to the bare /v1/score path (without explain=true). Those produce no composed prose, so there is nothing to learn.
Purpose: train a smaller composer model for richer area briefs without depending on third-party LLM infrastructure.
Storage: a dedicated store, kept separate from operational logs and from the planner data. Internal access is restricted, and our admin tooling shows aggregate counts only.
Both training corpora roll off automatically after 365 days. Rows older than that are purged nightly.
Raw training data is accessible only to a small number of internal administrators. Our admin tooling shows aggregate counts only, never the raw question text or brief body.
Each API key has a training opt-out setting, off by default. When you turn it on, requests made with that key are not added to either training set. Operational logging continues; opt-out applies to the training corpora only.
To toggle: sign in, go to /api-usage, and use the "Training" switch next to any of your keys. It takes effect on the next request from any client using that key. No support email needed.
user_id or org_id. Email support.We read everything that lands at operation@onegoodarea.co.uk and we usually reply within one business day.