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 v2 API is not separately addressable: requests to the documented endpoints return v3-generation data in the v2-compatible response shape. 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, administrative convenience fields, and the USPS carrier route. 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 — TQ0022 is a valid arm’s-length sale, TQ0013 a non-market or forced transfer — and appear on transfers[].saleCode for every sale event, 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 data exports today and come to API responses in an upcoming release. 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. 13 fields changed code vocabulary in v3 — among them wallType, roofType, roofStyle, garageType, basementType, constructionType, floorType, poolCode, lotCode, buyerIDCode, buyerVestingCode, forecloseCode, 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 16 of these debt and ownership analytics are frozen estimates captured May 2026. They were modeled estimates from our previous data provider 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.
One more, and we are pre-announcing it so you can plan for exactly one further change after this migration. Sale-qualification and price-derivation codes already use Realie’s own code system (TQ#### / PD####); building and characteristic code values migrate to prefixed Realie codes in an upcoming data release. The complete mapping will be published in the changelog before it ships.
No sunset date has been announced. The v2 API (legacy) tab preserves the v2 reference exactly as it documented the previous generation, 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.