> ## 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.

# Migration FAQ

> Common questions about moving an integration from the v2 to the v3 data generation.

Answers to the questions we hear most about the v3 data generation. For the
complete field-by-field delta, see the
[migration guide](/api-reference/v3/migration); for account, billing, and
pagination questions, see the [API FAQ](/api-reference/faq).

<AccordionGroup>
  <Accordion title="Will my integration break?">
    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](/api-reference/v3/migration).
  </Accordion>

  <Accordion title="Do I need a new URL, API key, or version header?">
    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](mailto: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](/api-reference/v2-legacy).
  </Accordion>

  <Accordion title="A field I used is missing from the response. What happened to it?">
    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](/api-reference/v3/migration#removed-fields-57).
  </Accordion>

  <Accordion title="What is realieParcelId, and why shouldn't I keep using _id?">
    `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](/api-reference/v3/migration#use-realieparcelid-not-_id).
  </Accordion>

  <Accordion title="Why are bathroom counts decimals now?">
    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](/api-reference/v3/migration#type-changes).
  </Accordion>

  <Accordion title="What are TQ#### and PD#### codes?">
    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](/api-reference/v3/feature-key).
  </Accordion>

  <Accordion title="Where do I decode coded fields?">
    The [Property Feature Field Key](/api-reference/v3/feature-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](/api-reference/v3/migration#code-vocabularies).
  </Accordion>

  <Accordion title="My useCode filter returns different results than it used to. Why?">
    `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](/api-reference/v3/feature-key) and the [Code vocabularies](/api-reference/v3/migration#code-vocabularies) notes rather than assuming data loss.
  </Accordion>

  <Accordion title="Why do recent sale events have no seller name or qualified flag?">
    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](/api-reference/v3/migration#data-freshness).
  </Accordion>

  <Accordion title="Are individually assessed condo units their own records now?">
    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](/api-reference/faq) covers unit-number normalization.
  </Accordion>

  <Accordion title="What happened to owner1FirstName, owner1LastName, and the other name splits?">
    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](/api-reference/v3/migration#owner-name-splits).
  </Accordion>

  <Accordion title="Are totalLienCount, LTV, and the equity fields still updating?">
    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](/api-reference/v3/migration#restored-fields-15).
  </Accordion>

  <Accordion title="What happened to the owner-search endpoints?">
    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](mailto:support@realie.ai).
  </Accordion>

  <Accordion title="Are more code vocabulary changes coming?">
    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](/api-reference/v3/feature-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](/api-reference/v3/changelog).
  </Accordion>

  <Accordion title="How long will the v2 reference stay available?">
    No sunset date has been announced. The [v2 API (legacy) tab](/api-reference/v2-legacy) preserves the v2 reference as it documented the previous generation — including the [Pre-v3 Code Tables (Frozen)](/api-reference/v2-legacy-code-tables) 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.
  </Accordion>

  <Accordion title="Who do I contact if a field still looks wrong?">
    Email [support@realie.ai](mailto:support@realie.ai) with the endpoint, the request parameters, and the `realieParcelId` of an affected property. Check the field against the [Property Data Schema](/api-reference/v3/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.
  </Accordion>
</AccordionGroup>

Still have questions? Email us at [support@realie.ai](mailto:support@realie.ai).