> ## 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 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](/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, administrative convenience fields, and the USPS carrier route. 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 — `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](/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. 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](/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 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](/api-reference/v3/migration#restored-fields-16).
  </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?">
    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](/api-reference/v3/changelog) before it ships.
  </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 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.
  </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).