Skip to main content
Answers to the questions we hear most about the v3 data generation. For the complete field-by-field delta, see the migration guide; for account, billing, and pagination questions, see the API FAQ.
Almost certainly not. v3 serves the same endpoints, the same authentication, and the same flat, v2-compatible response shape, and the large majority of v2 fields return under the same names with the same meanings. Four things are worth a look before the switch: whether you persist _id, whether you read the fixed past-sale fields, whether you decode any coded fields, and whether you treat bathroom counts as integers. Each is covered below and catalogued in the migration guide.
No. There is no new base URL, no version header, and no version parameter — your existing key and endpoint URLs keep working exactly as they are. The response shape is an account-level setting: existing accounts receive v3-generation data in the v2-compatible flat shape until you enable the v3 shape from the Usage page of your dashboard; new accounts start on the v3 shape. Enabling v3 is one-way — you can’t switch back from the dashboard, so update your parsers first (contact support@realie.ai if you need it reverted). Two current exceptions return the flat layout even on v3-enabled accounts: a small number of records resolved through legacy coverage fallbacks, and searches using foreclosure filters — both will be removed in a later release. See About the v2 Reference.
57 v2 fields have no equivalent key in v3, and they fall into a few families. 36 of them are the fixed per-event past-sale and last-sale slots (pastPriceSale, priorSalesDate, saleBookLastSale, and the like) — v3 returns the full event history in the transfers array instead, so page the array rather than reading fixed “past/prior” columns. The remaining 21 are owner-name splits, assessment component scalars, per-transfer deed flags, and administrative convenience fields, including the constant-valued ownerOriginCode. (The USPS carrier route is absent from the flat shape but remains available in the nested record as propertyLocation.siteCarrierRoute.) Every field and its replacement path is listed under Removed fields.
realieParcelId is the persistent parcel identifier, new in v3 and returned on every property. _id values are regenerated on each data load, so if you store _id and use it to re-fetch or join properties later, those references break at the next data release. Persist realieParcelId instead — it is stable across releases. See Use realieParcelId, not _id.
A bathroom-count data-quality improvement means fractional values are now real JSON numbers: a house with two full baths and a powder room returns totalBathrooms: 2.5, not a truncated 2. The same applies to fullBathrooms and halfBathrooms. If your code parses these as integers, or filters on bathsMin / bathsMax in the comparables endpoint, check that decimals are handled. See Type changes.
They are Realie’s own code system for sale events. TQ#### codes carry sale qualification — TQ0002 is a valid arm’s-length sale, TQ0001 a non-market or forced transfer — and appear on transfers[].saleCode wherever the source recorded a reviewed qualification signal (the key is absent otherwise), replacing the mix of per-source qualification vocabularies. PD#### codes record how the price figure was obtained (stated on the document, computed from transfer tax, from an affidavit, and so on); they ship in bulk exports and in the nested v3 response as salesHistory[].priceDerivation — the flat shape does not carry them. Both tables are published in the Property Feature Field Key.
The Property Feature Field Key is the single decode source of truth, for API responses and bulk deliveries alike. 15 fields changed code vocabulary in v3 — among them wallType, roofType, roofStyle, styleDesc, garageType, basementType, constructionType, floorType, poolCode, lotCode, buyerIDCode, buyerVestingCode, forecloseCode, transferDocType, and transfers[].saleCode. The keys are unchanged, but the values are not the v2 letter codes, so do not decode them against v2 tables. The full list is under Code vocabularies.
useCode itself is unchanged — the same 4-digit scheme as v2, and the search filter still matches exactly, by design. What changed is the coding of individual parcels: the current source retires a small number of v2-era codes and re-codes those parcels to more specific successors. In Florida, for example, the generic codes 4001 and 8017 are retired, and parcels that carried them now return a specific successor code. If a filter went quiet or shifted volume, re-tune it deliberately against the useCode table and the Code vocabularies notes rather than assuming data loss.
Sale histories now extend through mid-May 2026 in most states via a fast path that appends recent recordings, and those appended events carry a reduced record shape until they backfill in subsequent data releases. qualified is absent on nearly all events recorded after March 2026 — the qualification determination lags the recording — and seller (grantor) and title-company details are similarly not yet attached. Use transfers[].saleCode for qualification semantics on recent events; it carries the TQ#### codes. Note also that transferPrice is sparse on recent events in non-disclosure states such as Texas, where recorded documents do not carry a price. See Data freshness.
Yes. Condo and multi-unit parcels that the county assesses individually resolve to their own records, each with its own realieParcelId. Expect higher parcel counts in condo-dense areas, and expect an address search at a multi-unit building to return more parcels than it did under v2. Use unitNumberStripped to target a specific unit — the API FAQ covers unit-number normalization.
All six owner-name split fields are absent in v3. The current source delivers owner names as raw LAST FIRST strings in ownerName (and now also ownerName2), and there is no authoritative split today, so the keys are absent rather than empty strings. An owner-name parsing initiative may restore them in a future release. See Owner name splits.
They return under their exact v2 field names, but 15 of these debt and ownership analytics are frozen estimates captured May 2026. They were modeled estimates rather than recorded facts, so they do not refresh with new data releases and never mix into recorded mortgage and lien data. Three of them — totalLienCount, totalLienBalance, and lenderName — are computed from recorded records when those records are known, and fall back to the frozen estimate only when lien or mortgage data is entirely unknown for the parcel. See Restored fields.
Owner search is not part of the current API reference. The endpoint set documented for v3 is identical to the endpoint set documented for v2, so this is not a v2 → v3 data change. If your integration depends on owner search, contact support@realie.ai.
No. The building and characteristic code migration has shipped: every normalized coded field of both shapes now carries a value from the Realie code system (jurisdiction-issued fields such as taxRateCodeArea, land-use codes, and zoning codes stay verbatim), and the codebook is published complete in the Property Feature Field Key. Re-decode any coded values you persisted before this release. From here the codebook is append-only — a published code id never changes meaning and is never reused or renumbered; new codes join under the next free number, and every addition is announced in the changelog.
No sunset date has been announced. The v2 API (legacy) tab preserves the v2 reference as it documented the previous generation — including the Pre-v3 Code Tables (Frozen) archive for interpreting coded values you persisted before August 19, 2026 — so you can compare against what you built, and it will remain available while v2-era integrations are active. Bear in mind that the endpoint pages in that tab call the live API, so the playground returns v3-generation data.
Email support@realie.ai with the endpoint, the request parameters, and the realieParcelId of an affected property. Check the field against the Property Data Schema first — fields with no value for a parcel are omitted from the response rather than returned as null, which is unchanged from v2 and is not the same as a missing field.
Still have questions? Email us at support@realie.ai.