This is the authoritative quick reference for building a POST /property/search request body. Validate every field name and every enum value against the tables below before sending a request.

The searchCriteria.building object accepts these fields and only these fields. Use the names below verbatim.

For "square feet" / "sqft" / "sf" / "size" prompts, use livingAreaSquareFeet (heated/cooled space). Use totalBuildingAreaSquareFeet only if the prompt explicitly asks for total building area including non-living space (garage, porch, basement).

Range values use { "min": <number>, "max": <number> }; either bound may be omitted.

general.propertyTypeCategory and general.propertyTypeDetail are enumerated string filters with a closed value list. Use inList (multiple values) or equals (single value); the values below are the complete list, so partial matching is never needed.

Residential, Commercial, Industrial, Agricultural.

The value Garden Apartment, Court Apartment (5+ Units) is a single enum value that contains a comma — keep it as one string.

When a search describes a concept rather than a specific enum value, include the full inList of every value below. Always include every value in the expansion; never collapse to a single representative value.

"single family" / "SFR" / "single-family home" / "house" / "home" (when used as a property type):

"multi-family" / "multifamily" / "multi family":

"condo" / "condominium" / "condos":

"townhouse" / "townhome":

"mobile home" / "manufactured home":

"vacant land" / "land":

When the prompt does not name a property type, omit general.propertyTypeCategory and general.propertyTypeDetail entirely. Do not add filters the user did not request.

When the user specifies a number of units ("2+ unit residential", "3-unit", "4 or more units", "buildings with at least 5 units"), encode the count as a numeric range on building.unitCount (or building.residentialUnitCount if the prompt is residential-specific). propertyTypeDetail is an exact-match enum of named property types — it does not accept count-style values, and a unit-count expression belongs in the building filters, not the property-type filter.

If the user mentions both a unit count and a property-type concept ("2+ unit residential properties"), pair the building.unitCount filter with the multi-family propertyTypeDetail expansion above.

Use quickLists (AND semantics) or orQuickLists (OR semantics). Prefix with not- to negate (e.g. not-owner-occupied).

Use the umbrella absentee-owner when the user says "absentee" without specifying in-state vs out-of-state. The in-state and out-of-state variants are subsets — picking only one of them silently drops the other half.

When a search uses one of the phrasings below, always include the corresponding quicklist. These mappings are mandatory: omitting the quicklist drops the intent of the search.

For "mailing address is different from the property", use the not- prefix on the existing quicklist (not-same-property-and-mailing-address). There is no different-property-and-mailing-address quicklist, and no mailingAddressHash workaround is needed.

These are independent of any other filters in the prompt. For example, "owner-occupied homes in Austin with high equity" requires both owner-occupied and high-equity in quickLists. Do not drop a required quicklist because another filter (property type, location, range filter) is also present.

Quicklists combine with AND. Pick one quicklist per group below: a contradictory pair (such as owner-occupied with absentee-owner) matches zero records, and a subset pair (such as absentee-owner with out-of-state-absentee-owner) simply narrows to the subset, so name the single most specific list instead.

If the user's prompt itself contradicts (e.g. "owner-occupied absentee owner"), pick the more specific filter; do not emit both.

Some concepts have no quicklist and must be expressed as numeric range filters:

There is no negative-equity quicklist; do not invent one. low-equity means under 20% equity, which is a different (and less extreme) concept than negative equity, so do not substitute it for "underwater". Use the valuation.equityPercent numeric filter.

When a prompt mentions a time window for a foreclosure, listing, or sale event ("notice of default in last 90 days", "auction in March", "sold this year", "listed Jan 1 to Jan 31"), the quicklist alone is not enough. You must:

Compute minDate / maxDate from the actual current date when generating a body — never use placeholder or training-cutoff dates.

BatchRank sale-propensity filtering lives in the searchCriteria.intel group. There is no flat, top-level propensity field and no min_sale_propensity / max_sale_propensity parameter — those names do not exist in the API.

Key facts:

When the prompt does not name a property type, do not add general.propertyTypeCategory or general.propertyTypeDetail — leave them out, as in this example.

These optional fields live under options on a Property Search request.

Default paging (small result sets):

Exceeding the cap returns a 400 whose message states the limit explicitly, e.g. "The options.take must not be greater than 100." on sync /property/search and "The options.take must not be greater than 1000." on /property/search/async. If a caller reports a different limit than the one above, follow the number in the API's own error message rather than restating a fixed value.

Retrieving large volumes (tens of thousands of records). Do not deep-page with bare skip/take — skip-based deep paging is unstable as the index shifts underneath you, so rows can be duplicated or missed between pages as results move across page boundaries. In descending order of preference:

Arithmetic for 50,000 records: ~500 requests against sync at take: 100 (cursor pagination makes the same number of requests, but pages stably), or ~50 against async at take: 1000. Request count is rarely the binding constraint — billing is per record returned, not per request, and the rate limit is 3,000 requests per minute per account — so prefer cursor pagination for stability rather than to save requests. The MCP tools' 10-results-per-page behaviour is a tool-layer limit and must never be quoted as an API limit or used to compute request counts for someone building their own integration.

Cursor pagination (stable paging through large result sets; supported on both sync /property/search and async /property/search/async — on async, the webhook payload carries results.nextPageCursor in the same shape):

Search session (named, persistent delivery context across requests, sync /property/search only):

Constraints (verbatim 400 error strings):

Token ability required for sessions: property-search-sessions (also gates GET /api/v2/property/search-sessions and DELETE /api/v2/property/search-sessions/{id}). 100 sessions max per account.

Response fields added on Property Search:

Example — session-backed paging:

contains, startsWith, and endsWith return an HTTP 400 error naming the field and operator on the high and medium cardinality text fields listed below. On these fields use equals, inList, notInList, or matches instead.

owner.firstName and owner.lastName additionally accept containsWords (see Owner-name search below). The wildcard operators remain available on the low-cardinality enumerated fields, for example address.state, address.zip, property type, and most other status and type enums. Note the restriction applies to the text title fields (address.cbsaTitle, address.csaTitle), not to their numeric code counterparts.

matches is a complete-value operator like equals, not a partial-match substitute. matches appears in the replacement list above because it is still accepted on every field in it. It will not match a fragment of a stored value, and matches with more than one value behaves differently from field to field and returns zero on several of them, so use inList to match any of several values.

Never offer matches as a partial-name or keyword workaround, on any string field. It requires the complete stored value, so a fragment returns zero results with an HTTP 200, and nothing in the response signals the query was wrong. When only part of a value is known, route to equals or inList with complete values, or to containsWords on owner.firstName and owner.lastName, which is the one tokenized owner-name operator.

Supply exactly one operator per field. If a field carries more than one operator, the API applies one and silently discards the rest, with HTTP 200 and no error or warning in the response. Of the eight text operators matches ranks last, so on a field that accepts matches, a matches clause paired with any other operator is the one that gets dropped. The loan-type fields do not accept matches at all, so supplying it there makes the request fail instead; these are the openLien loan-type fields (allLoanTypes, juniorLoanTypes, and firstLoanType through fourthLoanType). The silent discard applies when the field accepts every supplied operator: if any supplied operator is not accepted on the field, the request fails instead, so a wildcard paired with equals on a restricted field still returns its HTTP 400. Two different operators on the same field cannot be combined in one request. To match any of several values, use inList.

Filter Property Search to a known subdivision:

Use inList to span a set of subdivisions, or notInList to exclude them.

Comparables in the subject's subdivision — use options.useSubdivision: true:

useSubdivision: true derives the subject's subdivision from compAddress automatically — equivalent to passing the subject's legal.subdivisionName in an equals filter, but simpler. Set the explicit legal.subdivisionName clause only when comparables in a different subdivision are needed, or inList across multiple.

If the customer only has a fragment of the subdivision name, look up any property known to be in the subdivision via Property Lookup and copy the response's legal.subdivisionName verbatim into the equals or inList clause. Do not paraphrase, lowercase, or trim it.

To find a property by its owner's name, use containsWords on owner.firstName and/or owner.lastName. It is a tokenized, order-insensitive, case-insensitive word match and is the supported replacement for wildcard matching on owner-name fields. 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. The same-owner rule applies when both names use containsWords or both names use equals or inList. If you use containsWords for one name and equals or inList for the other, the API checks each name separately. The two names can then match two different owners on the same property. A search that uses containsWords on either name requires a location, such as a city and state, a ZIP code, or a full address. Without a location, the request returns HTTP 400. An owner-name search that uses only equals or inList does not require a location.

For a containsWords search, set options.ownerNameAddressMatchMode to control address handling:

Mapping common phrasings:

Confirm an owner at a specific address (exact mode):

searchCriteria.previousOwner.fullName matches a party against the seller of record on the property's past sales. Use it to find properties a party sold, as opposed to owner.*, which finds properties a party currently owns. The common case is a fix-and-flip investor or a company whose past sales the customer wants to study.

Operators. Supported: equals, inList, notInList, matches. Matching is case-insensitive. All four operators compare against the complete stored name, never against a fragment of it: matches is not a partial, prefix, or keyword search. Supplied with a single name it is identical to equals, and more than one value returns no results on this field, so use inList to match any of several names. containsWords is not supported on this field, so do not carry the owner-name recipe over to it. contains, startsWith, and endsWith return HTTP 400 like the other restricted string fields.

Limitation. State this in every answer that uses this filter. Matching applies to the seller of record on the two most recent sales only. It does not search a property's full ownership or transaction history, so a sale further back than that will not match. When a customer asks for everything a party has ever transacted, point them at Investor Profile rather than this filter.

Mapping common phrasings:

Properties a named party sold at a location:

Several parties at once (inList):