Skip to main content
​
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 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).
​
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; per-jurisdiction vendor code values that had no published meaning are no longer reproduced (see the migration guide 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. If you captured responses before this date, re-capture before validating decoders — earlier responses came from the previous data generation.
​
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.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 update at the same time. The v3 Feature Field Key includes the flat-shape field-name mapping.
​
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. 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, 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.
​
Feature Field Key covers bulk record fields
The Property Feature Field 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).
​
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.
  • Some coded fields use different code vocabularies than v2. Decode every value with the Property Feature Field 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 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.