August 2026

Owner-name search on the Property Search API now requires both supplied name parts to describe the same owner, and the ownerNameMatch response block reports one consolidated count in place of a separate count for each name part. If your integration reads firstNameMatchCount or lastNameMatchCount, it needs to change.

Both name parts must match the same owner. When you supply both owner.firstName and owner.lastName, a property matches only if both names appear on the same owner record. When both names use containsWords, satisfying one name through one owner and the other through a second owner is not a match. Supplying a single name part matches it against either owner. When both names use containsWords, the same-owner rule applies in both standard and exact address-match modes. It also applies when both names use equals or inList. Such a search runs only in standard mode. If you use containsWords for one name and equals or inList for the other, the API checks each name separately, in either mode. The two names can then match two different owners on the same property.

firstNameMatchCount and lastNameMatchCount have been removed. The meta.results.ownerNameMatch block, returned in exact mode, previously carried one count for each name part. Both fields are gone, replaced by a single ownerNameMatchCount. The block now returns matchedParcelCount, ownerNameMatchCount, trustMatchCount, and matchSource. This is a breaking change to the response shape, so read the new field name rather than either removed one.

A combined first-name and last-name search previously returned the union of the two parts, so a property matched when either part matched any owner on the record. It now returns their intersection. Results are fewer and more precise.

For example, in a city where a first name appears on hundreds of owner records and a last name on only a few, the combined search previously returned every property matching either part. It now returns only the properties where both names sit on the same owner, typically a handful or a single record.

In exact mode the response includes an ownerNameMatch object under meta.results carrying matchedParcelCount (the total, and the value to use for the zero / one / more-than-one decision), ownerNameMatchCount and trustMatchCount (attributions explaining how those parcels were reached, which overlap rather than dividing the total between them), and matchSource, which reports which address the match came from. ownerNameMatchCount counts parcels carrying every supplied name part on the current owner record, and trustMatchCount counts parcels reached through the trust deed look-back. Because the two attributions overlap, do not expect them to add up to matchedParcelCount. standard mode omits the ownerNameMatch object.

Still in exact mode, for a trust-owned property the look-back also matches recent deed parties, and both names must describe the same deed party.

Confirm whether John Smith is on the owner record at a specific address:

The ownerNameMatch block returned under meta.results:

Here one parcel matched, and both attributions report it, because the name is on the current owner record and on a recent deed party. That is the overlap described above, not a count of two separate parcels.

Owner-name search is billed on the existing property-data meter. A returned property record consumes property-data quota as usual, and there is no separate charge for the match.