Which Property Search Filters Actually Change Your Results

A filter your schema accepts is not a filter the source honors. We ran the transaction-type and property-type filters across 14 property APIs to find out which ones reach the underlying board. Most do. Two refused in ways no schema reading would have predicted, and both refusals arrived as a clean message rather than as wrong data — which is the good case, and not one to count on.

What does transaction-type support look like across sources?

Three tiers, verified by running each one and counting returned rows:

• Sale, rent and sold — 7 sources. The multi-source aggregators plus the US and Canadian majors. Sold listings are the differentiator: they answer the comparable-pricing question that live inventory cannot.
• Sale and rent — 6 sources. The UK, Australian, Indian and South African boards in our set. Full rental coverage, no closed-transaction history.
• Sale only — 1 source. One major US board accepts nothing but for-sale in this route, which quietly caps what you can ask it.

The practical consequence is that a sold-listing analysis eliminates more than half the sources before you write a line of code, and a rental study eliminates one. Choosing the source first and discovering the constraint later is the expensive order.

Why did a schema listing 11 property types reject all of them?

This was the surprising result. One source declares 11 normalized property types — residential, house, apartment, condo, land, commercial and more — and rejected a condo filter outright, answering: no selected platforms support the selected listing_type, property_type, or posted_since.

The declaration and the routing are separate layers. A schema shared across a family of sources lists the union of what any of them can do; each individual route supports a subset. Read alone, the schema promises 11 filters. Executed, that route supports none of them. The same pattern hit a Nordic market where the rental filter is accepted by the schema and unsupported by the board behind it.

Neither returned bad data. Both returned nothing, with an explanation. That is the well-behaved version of this failure — and it is why a zero-row result deserves a log read rather than a shrug, because the log distinguishes “no inventory matched” from “this filter was never going to work here.”

How do you test a filter in two minutes?

Run it, once, and compare against the unfiltered query in the same market:

1. Run the search with no optional filters. Note the row count.
2. Add the one filter you care about. Run again.
3. Rows drop but stay non-zero — the filter reached the source and narrowed it. Usable.
4. Rows go to zero — read the log. An explicit unsupported-filter message means the route ignores it; silence with genuinely thin inventory means the market is small.
5. Rows do not change at all — suspect the filter was accepted and dropped. Spot-check five records against the criterion before trusting it.

That last case is the dangerous one, and the only one that produces confidently wrong analysis instead of an obvious blank.

Which filters are worth building on?

Transaction type is the one that reliably changes the dataset, because boards organize their own inventory around it — rentals and sales are separate sections with separate fields. Sold is the most valuable and the least universally available, and it is worth choosing your source for.

Property type is less reliable across aggregated routes for the reason above: it is a normalization layer over boards that categorize differently, and the mapping is where support gets lost. Verify it per source rather than assuming a shared vocabulary means shared behavior.

Recency filters sit in the same message as property type in at least one implementation, which is a hint that they travel together through the same routing check. Test them the same way.

What does this change about source selection?

Pick the transaction type first, then the geography, then the source — not the other way around. A rental yield study and a comparable-sales model have almost disjoint eligible source lists, and the geography you can cover follows from that choice rather than preceding it.

Then verify the specific combination you intend to run, in the market you intend to run it, before the pipeline exists. Ten minutes of runs converts a schema’s promises into a map of what actually answers. Everything above came from exactly that exercise, and two of the fourteen ended up somewhere other than where their schema said they would.