API changelog

Versioning

Everything under /v1 is additive. New fields, new routes and new values of an existing field (a new exclusion reason, say) can appear at any time, so a client must ignore what it does not know.
A field is never removed or given a different type or meaning inside /v1. A change like that ships as /v2, and /v1 keeps working next to it.
Every response body carries schema_version. null means a figure was not determined; an empty list means it was determined and there were none.
The analysis engine changes over time and a cached report is served for up to 30 days. meta.engine_version is the build that made a report, so the same address can give slightly different figures from a cached read and a fresh run when the engine changed in between; compare engine_version (and meta.generated_at) before treating a difference as a change in the market.

A client that supports MCP authorization can connect without an API key: the first time you use something that needs one (questions, fresh analyses, narratives), you are sent to sign in with Google and allow the app. It then spends your own daily limits; keyless use is unchanged.
GET /v1/usage returns what a key, an access token or an address has used today against its limits, and doubles as a check that a credential is valid.
Connected apps are listed under Account, Connected apps, where each can be disconnected at once.

MCP: every tool now has a title and read-only hints. get_report takes only a report_id and never starts an analysis; use analyze_property for an address.
search.radius_mi, search.widened and search.window_months are filled in: the radius of the fetch that produced the pool (null for Cook County's neighborhood-based comps, which have no radius), whether the search was widened past its first attempt, and the months of sales it looked back.
The versioning notes now say how to read a difference between a cached read and a fresh run (meta.engine_version).

POST /v1/ask reuses a finished answer for a day: the same question about the same address returns the earlier job (it polls as complete at once), costs no question quota and counts as a cached read.
A question about an address CompBasis has already analyzed starts from that analysis's own figures, so an answer agrees with the report and needs fewer lookups.

comps[] items carry in_range: true when the comp's price set the range's midpoint, false when it passed the filters but the range did not use it. The cap of 50 shows the caller's own comps, then the comps the range used, then the others, so a large pool never crowds out the evidence. search.kept counts the in_range comps.
Changed: the comparable-sales rows (comps[] and excluded_comps[]) are returned only with an API key. Without one comps is [], excluded_comps is null, search.comps_withheld is "key_required" and gaps[] says so; the range, the counts in search and every other section are unchanged.
Fixed: parallel requests could all pass the same daily quota or spend-cap check and overshoot it. The run is now reserved under a lock that decides again; a request that loses gets the same 429 or 503 and nothing starts.

GET /v1/coverage carries a service block: whether a new analysis can start now (available, or paused with the reason and the seconds to 00:00 UTC). The status line on the developer page reads it.
This changelog and the versioning policy above.

POST /v1/analyze takes comp_radius_miles, exclude_comps[] and include_comps[]. A request that uses any of them is private, is not widened past what you set, and shows the comps you added with provenance "user" and confidence capped at Medium.
comps[] items carry provenance (data or user). excluded_comps[] can now give the reason caller_excluded.

excluded_comps[] lists the candidates the filters dropped (up to 200, nearest first) with the reason: distance, subject_itself, property_type, unit_count, size_band, non_house_record, teardown_sale or outlier. null means the analysis predates the log.
search.kept, search.excluded, search.candidates and search.filters are filled in. search.kept is how many comps actually fed the range.

POST /v1/ask takes a question and an address and answers from public data, as a job you poll at /v1/jobs/{id} (the finished job carries answer). It needs an API key; a free key has 20 questions a day.
Fixed: the question tool could not answer location questions (flood zone, amenities) for some addresses because the address came back with no coordinates. It now takes the point from the Census geocoder.

A remote MCP server with analyze_property, get_report, get_job, list_coverage and ask_about_property. It calls this API, so the limits and the report are the same. Send your key as a bearer token on the connection.

POST /v1/analyze, GET /v1/jobs/{id}, GET /v1/reports/{id}, GET /v1/reports/by-address and GET /v1/coverage, with a published OpenAPI description.
Free API keys (Account, API keys): 20 fresh analyses, 5 narratives and 500 cached reads a day. Without a key, 3 fresh analyses a day per IP address.
A comps-free JSON copy of every public report at /report/<slug>.json, and /llms.txt for agents.