> ## Documentation Index
> Fetch the complete documentation index at: https://docs.realie.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Data and contract changes in the Realie Property Data API.

<Update label="August 20, 2026" description="Foreclosure history union; assignmentsReleases recordType populated">
  **Foreclosure history union.** Foreclosure records from the pre-v3 pipeline —
  events the current source feed does not carry, largely pre-2020 — are restored
  into the `foreclosures[]` array, deduplicated against the existing entries (a
  legacy record is skipped when a record within ±30 days of its recording date is
  already present). What this changes:

  * Restored entries carry `recordingDate`, `caseNumber`, `auctionDate`, and a new
    member **`foreclosures[].fileDate`** — the court filing date, when distinct
    from the recording date; the legacy pipeline recorded both.
  * Restored entries carry `recordType` `FR0001` (lis pendens class) or `FR0008`
    (notice-of-sale class). Legacy event classes with no equivalent code in the
    published vocabulary (late-stage/REO and unknown classes) carry **no
    `recordType`** — the member may now be absent on restored records.
  * The flat field **`forecloseFileDate`** is restored, served from the latest
    foreclosure record's `fileDate`. See the
    [migration guide](/api-reference/v3/migration) for the updated field lists.

  **`assignmentsReleases[].recordType` now populated.**
  `mortgages[].assignmentsReleases[].recordType` (`assignment` / `release`) —
  documented but never populated until now — carries a value from this snapshot
  onward (99.8%+ of entries; null when the source record is ambiguous or
  unmatched).
</Update>

<Update label="August 20, 2026" description="The API now serves the v3 data generation">
  As of **August 20, 2026**, every Property Data API response is served from the v3
  data generation, for all states. What this means per response shape:

  * **Flat (default) shape** — the response structure is unchanged; values now come
    from the v3 record through the compatibility projection. Coded fields carry only
    letters whose meanings are published in the
    [v2 legacy code tables](/api-reference/v2-legacy-code-tables); per-jurisdiction
    vendor code values that had no published meaning are no longer reproduced (see
    the [migration guide](/api-reference/v3/migration) for the field-level list).
  * **Nested (v3) shape** — opt-in from the Usage page — carries the full v3 record,
    including the Realie code system announced below, and
    `salesHistory[].priceDerivation` (`PD####`), previously bulk-only. The flat
    shape does not carry `priceDerivation`.

  Decode every coded value with the
  [Property Feature Field Key](/api-reference/v3/feature-key). If you captured
  responses before this date, re-capture before validating decoders — earlier
  responses came from the previous data generation.
</Update>

<Update label="August 2026" description="The Realie code system — every coded field, one national codebook">
  Every normalized coded field of the v3 parcel record now stores a value from the
  **Realie code system**, replacing the mix of inherited source vocabularies (the
  deliberate exception is the jurisdiction-issued fields — `taxDistrictCode`,
  county/state land-use codes, and `zoningInfo.zoningCode` — which carry each
  jurisdiction's own value verbatim). This is the migration
  announced at the v3 launch, now complete: one national codebook, applied identically
  in API responses and bulk full-record exports, documented in full in the
  [Property Feature Field Key](/api-reference/v3/feature-key).

  **How coded values are represented.** Coded facts appear in one of three
  representation classes:

  * **Realie codes** (`XX####`) — a two-letter family prefix plus a four-digit number
    (e.g. `RM0001`, COMPOSITION SHINGLE). The digits identify, they do not rank —
    never compare or compute on them; decode with the published tables. The 4-digit
    property-use vocabulary keeps its familiar form and unchanged code identities.
  * **Integer ordinal and band scales** — genuinely ordered values: `building.quality`
    and `building.condition` are integers on a 1–20 scale (two separate facts sharing
    only the scale form), and the legacy length-of-residence, LTV-range, and
    equity-range members are integer band indexes.
  * **Numeric quantities** — real measurements stored as numbers, such as
    `mortgages[].rateChangeFrequency` (an interval in years).

  **The codebook is append-only.** Once published, a code id never changes meaning
  and is never reused or renumbered. New codes join under the next free number, and
  every addition is announced here. The append-only guarantee applies from this
  release forward.

  **Schema changes in this release**

  * `salesHistory[].qualification` now carries the `TQ####` qualification code
    (previously a Q/U flag), and a new boolean **`salesHistory[].armsLength`**
    carries the derived arm's-length verdict. `salesHistory[].salePriceCode` is
    removed — its content lives in `qualification`. The flat shape's
    `transfers[].saleCode` now corresponds to `qualification`.
  * Building systems are documented as structured objects: per-building
    `characteristics` (buildingType, architecturalStyle, exteriorWall, roofMaterial,
    quality, condition, parking, driveway, pool, amenities, and more), `heating`
    (five facets: equipment, distribution, energySource, configuration, coverage),
    and `cooling` — with top-level `building`, `heating`, and `cooling` summaries for
    the primary building. They replace the former per-building `*Code` members
    (`heatCode`, `airConditioningCode`, `qualityCode`, `conditionCode`, `styleCode`,
    `wallType`, `roofType`, `floorType`, `basementType`, `constructionType`,
    `garageType`, `poolCode`, `drivewayType`, and related label fields).
  * Buyer information on sale events is now four facets — `buyerEntityType`,
    `buyerRelationship`, `buyerRole`, `buyerVesting` — replacing `buyerIDCode` and
    `buyerVestingCode`.
  * `mortgages[].riders[]` and `buildingInformation.buildings[].buildingAreas[].areaType`
    now carry codes (`RD####` / `BA####`) instead of ad-hoc labels;
    `mortgages[].amortizationType` (`LA####`) is new; `mortgages[].rateChangeFrequency`
    is now a numeric interval in years.
  * `utilities` now carries `waterSource`, `sewer`, `gasService`, and
    `electricService` as coded members; `landInformation` gains `roadAccess`,
    `waterfrontType`, and `viewQuality`; `taxInformation` gains `taxClass`. Several
    of these ship their vocabulary ahead of their data and populate in later releases.
  * **Renamed:** `landInformation.topographyType` is now
    **`landInformation.topography`**, carrying a `TP####` code. Nested-shape clients
    reading the old key should switch; the field has no equivalent in the flat shape,
    so flat-shape integrations are unaffected.
  * **Zoning has one surface**: the `zoningInfo` object. Its `matchMethod`
    distinguishes the two provenance tiers — `assessor_recorded` (baseline, from the
    county assessor's own record) and `gis_point_in_polygon` (curated, from the
    zoning jurisdiction's GIS layer). The duplicate raw member
    `propertyClassification.zoning` is removed.
  * Removed members no longer reproduced by the record:
    `propertyClassification.propertyCategory`, `.propertyUse`, `.propertyClassCode`
    (replaced by `propertyClass` as a `PC####` code), `landInformation.landUseCode`,
    `generalInformation.utilities`, `taxInformation.assessmentClassification`,
    `salesHistory[].deedType`, `.instrumentType`, `.instrumentCode`, and
    `legacyOwnershipSummary.ownerOriginCode`.

  **taxDistrictCode data change.** `taxInformation.taxDistrictCode` — exposed in the
  flat shape as **`taxRateCodeArea`** — now carries the **assessor's tax-district
  code** wherever the source provides one, carried verbatim as a jurisdiction-issued
  value. Stored values change in Maryland, Delaware, and the District of Columbia as
  part of this correction; if you keyed logic to previous values in those areas
  (under either field name), re-sync from this release.

  **Disclosure — values shipped empty pending documentation.** Across the national
  dataset, 20,439 coded value-instances could not be confirmed against any published
  source documentation at release time. Rather than guess, these ship empty — the
  member is **omitted** from the record, as for any field with no value, not returned
  as null — and are being backfilled **in place** as county documentation is
  confirmed. Backfills add values under existing append-only vocabularies and never
  change a published code's meaning. No action is needed; affected records simply
  gain values in subsequent data cycles.

  **Legacy (v2-compatible) flat shape.** The flat shape carries the same underlying
  values, so its coded fields change with this release too; the decode tables on the
  [legacy tab](/api-reference/feature-key) update at the same time. The
  [v3 Feature Field Key](/api-reference/v3/feature-key) includes the flat-shape
  field-name mapping.
</Update>

<Update label="August 2026" description="The v3 response shape — one dataset, two shapes">
  The v3 API's standard response is now documented as the **full nested parcel
  record** — matching bulk exports apart from delivery-specific fields such as the per-load `_id` — in the
  [v3 Property Data Schema](/api-reference/v3/property-data-schema). The shape is an
  **account-level setting**, and every API key on an account inherits it: new accounts
  start on the nested shape; existing accounts continue to receive the
  **v2-compatible flat shape** (the same v3 data through a compatibility layer), now
  documented in the [legacy tab](/api-reference/property-data-schema), until they
  enable the v3 shape from the dashboard's **Usage** page. Enabling it is one-way.
  Field values and codes are identical between shapes.
</Update>

<Update label="August 2026" description="Feature Field Key covers bulk record fields">
  The [Property Feature Field Key](/api-reference/v3/feature-key) now documents the
  coded members carried by **bulk full-record exports** alongside the API response
  fields — 37 decode tables in total, covering building systems (`heatCode`,
  `qualityCode`, `conditionCode`, `styleCode`, ...), mortgage codes (`loanType`,
  `interestRateType`, ...), lien and foreclosure record types, and the sale
  qualification flag. Every published table is verified against the live national
  data domain (1.19 billion additional coded values, 100% decode on 20 of 21 new
  tables).
</Update>

<Update label="August 2026" description="v3 data generation launch">
  The API now serves the **v3 data generation** — a rebuilt national dataset on the same
  endpoints and response shape.

  **Data improvements**

  * Sales history extends through **mid-May 2026** in most states (previously \~4 months
    older), including ownership updates from recent sales.
  * Per-unit parcel identity: every response carries a stable **`realieParcelId`**;
    condo and multi-unit parcels resolve to their own records.
  * Corrected building characteristics nationally (notably bathroom counts, which are
    now decimal — `2.5` instead of a truncated `2`).

  **Contract changes**

  * A small set of v2 fields are renamed, restored under new names, or no longer
    reproduced; several derived-description fields replace raw code fields. Full list in
    the [migration guide](/api-reference/v3/migration).
  * Some coded fields use different code vocabularies than v2. Decode every value with
    the [Property Feature Field Key](/api-reference/v3/feature-key).
  * Sale-qualification codes ship in the **Realie code system**: `transfers[].saleCode`
    carries `TQ####` qualification codes wherever the source recorded a reviewed
    qualification signal, and bulk exports include
    the new `priceDerivation` (`PD####`) field recording how each price figure was
    obtained.

  **Coming**

  * ~~Assessor code values will migrate to **Realie's own code system**~~ — **Shipped.**
    The migration is complete and live in API responses as of August 20, 2026; see
    the code-system entry above and the
    [Property Feature Field Key](/api-reference/v3/feature-key) for every table.
  * ~~`priceDerivation` exposure in API responses~~ — **Shipped August 20, 2026** on
    the nested shape as `salesHistory[].priceDerivation`; the flat shape does not
    carry it. (Bulk exports had it from launch.)
  * Derived `qualified` booleans on post-March 2026 sale events arrive with the next
    data cycle; `transfers[].saleCode` already carries the qualification codes.
</Update>