What Criteria filters for a recent eviction? (Team plan)

Setup: Team plan. Pulling North Orange County (County FIPS 06059) segments with POST /v1/properties using free counts (Purchase=0). Most criteria work great. One question and one clarification.

Question: what is the correct Criteria to filter recent evictions?

inProbateProperty works exactly as expected and returns a count:

curl -s -X POST 'https://api.propertyradar.com/v1/properties?Purchase=0&Limit=1' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{"Criteria":[{"name":"County","value":["06059"]},{"name":"inProbateProperty","value":["1"]}]}'
# -> 200 {"results":[],"totalCost":0,"resultCount":0,"quantityFreeRemaining":13597,"totalResultCount":316}

But hasRecentEviction returns HTTP 200 with an empty envelope and no count fields at all (it is not a 400 “Unexpected Criterion”, and not an upgrade error):

curl -s -X POST 'https://api.propertyradar.com/v1/properties?Purchase=0&Limit=1' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{"Criteria":[{"name":"County","value":["06059"]},{"name":"hasRecentEviction","value":["1"]}]}'
# -> 200 {"results":[]}

For reference, a truly unknown field name returns a clean 400:

# {"name":"fooBarBaz","value":["1"]}  ->  400 {"error":"Unexpected Criterion: fooBarBaz #1"}

What is the correct Criteria field name and value format to filter for properties with a recent eviction? Or is eviction only available as a Response field, not a filterable Criterion?

Clarification (no action needed, just confirming your note)

You mentioned the “cannot be used by this user” errors come from putting Response fields into Criteria. That matches what we see:

# {"name":"isRecentSale","value":["1"]}   -> "The param: isRecentSale cannot be used by this user" (feature not in plan)
# {"name":"isFreeAndClear","value":["1"]} -> "The param: isFreeAndClear cannot be used by this user"
# {"name":"SaleDate","value":["from: 2024-07-01"]} -> "The feature [Trustee Sale Tracking] is not included..."

We are already working around these (recent sales via LastTransferRecDate “from:”, equity via EquityPercent), and we do not need Trustee Sale Tracking. So the only open item is the eviction filter above.

Thanks!

Hello!

The error occurs because hasRecentEviction is not available as a standalone search criterion. Instead, use the In Distress criteria described in our documentation. This allows you to filter by that signal flag, along with other distress-related indicators.

Similarly, isRecentSale is a result field rather than a searchable criterion. To filter for recently sold properties, you can instead use the Purchase Date criteria.

isFreeAndClear is also a result field and cannot be used directly as a criterion. To find properties that are likely free and clear, use the Equity criteria and filter for an estimated equity percentage of 100%.

The Sale Date field is a special case because it is part of our Trustee Sale Tracking data. It represents the scheduled auction date for a property, not the date the property was purchased or transferred.

Access to this field requires the Trustee Sale Tracking add-on, which is licensed by county. Without that add-on, you can use the Original Sale Date field instead. Please note that Original Sale Date is not updated with subsequent trustee-sale activity unless Trustee Sale Tracking is enabled:

For more information about the differences between criteria and result fields, as well as the data available through the API, please review our documentation:

Please let us know if you have any additional questions!


Hopefully the last question - thank you for you****r assistance: Bolded Text Below


Support gave us clean answers. The important one for us: hasRecentEviction isn’t a standalone criterion. The eviction signal lives inside the “In Distress” criterion (a multi-value filter of distress flags). Let me get the exact criterion name and the eviction value from their docs, then confirm it against the live API (free call) so we know it actually works before relying on it.

Fetching the “In Distress” criteria doc for the exact criterion name and the eviction value:

:record_button:Fetch(https://developers.propertyradar.com/docs/in-distress)
Received 0 bytes (404 Not Found)
Allowed by auto mode classifier

Let me find the exact doc URL:

:record_button:Web Search(“PropertyRadar API “In Distress” criteria reference eviction value”)
Did 1 search in 9s
Allowed by auto mode classifier

The criterion is inDistress (multi-value), and there’s also an EvictionFilingDate criterion for eviction-filed-in-last-60-days. Let me pull the exact names and values from the criteria reference:

:record_button:Fetch(https://developers.propertyradar.com/criteria_reference)
Received 2.8MB (200 OK)
Allowed by auto mode classifier

The docs pages are JS-heavy and didn’t render the fields, but the search gave me the candidates. The authoritative check is the live API itself. Probing the real endpoint (free Purchase=0) to find exactly which criterion returns eviction-flagged properties:

Ran 1 shell command

That’s the definitive answer. The API’s own error enumerated every valid inDistress value, and hasRecentEviction is a value of the inDistress criterion, not a standalone field. That’s exactly what support meant. Even better, that same list contains most of our roadmap segments. Confirming the eviction filter returns real counts, plus the two other segments we care about (free calls):

Ran 1 shell command

One important nuance jumped out: inDistress=hasRecentEviction is accepted (it’s in the valid list) but still returns the empty envelope with no count, while every other distress flag returns a real number. And EvictionFilingDate since Jan 2025 showed just 1 property in all of Orange County. That points to eviction data being effectively unavailable for us, not a syntax issue. Let me confirm with an all-time eviction window before I conclude:

Ran 1 shell command

Now it’s conclusive. EvictionFilingDate all-time (since 2015): 1 in Orange County, 34 in all of California, 399 in all of Texas. Those are impossibly low for real eviction volume (a single large county sees tens of thousands a year), so PropertyRadar’s eviction dataset is essentially unpopulated nationally and effectively empty for CA. Support’s syntax answer was right, but the data isn’t there.

Recording this resolution in memory, then here’s the read:

Wrote 1 memory

Here’s the resolution, and it cuts two ways.

Support was right on the syntax. Evictions aren’t a standalone field. You filter them with the inDistress criterion, value hasRecentEviction. I confirmed it straight from the API’s own error, which enumerated every valid inDistress value. The nice surprise: that single criterion covers almost our entire segment roadmap (probate, death-of-joint-tenant, expired listings, out-of-state owners, preforeclosure, tax delinquency, divorce, and more), so we can filter all of them precisely now.

But the eviction data itself is essentially not there. This is a coverage problem, not a syntax one:
- inDistress=hasRecentEviction returns an empty envelope with no count, while every other flag returns a real number.
- EvictionFilingDate all the way back to 2015: 1 record in Orange County, 34 in all of California, 399 in all of Texas. Those are impossibly low for real eviction volume, so PropertyRadar simply doesn’t carry usable eviction data here.

Bottom line: the “court-sourced evictions” half of the beachhead can’t be sourced from PropertyRadar. It would need a separate court-records vendor. The tired-landlord half is untouched, since that pilot cohort is built on absentee + equity + distress, not evictions.

The upside is real, though. The segments that ARE loaded, with live Orange County counts:

┌────────────────────────────┬──────────┐
│ Segment (inDistress value) │ OC count │
├────────────────────────────┼──────────┤
│ Out-of-state owner │ 50,264 │
├────────────────────────────┼──────────┤
│ Death-of-Joint-Tenant │ 4,423 │
├────────────────────────────┼──────────┤
│ Expired listing │ 608 │
├────────────────────────────┼──────────┤
│ Preforeclosure │ 582 │
├────────────────────────────┼──────────┤
│ Probate │ 318 │
└────────────────────────────┴──────────┘

Death-of-Joint-Tenant at 4,423 stands out. That was Gemini’s #1 ROI pick when we ranked segments, and now we know it’s richly populated and precisely filterable.

I changed nothing in the working pilot. Your call on the eviction gap:
- Recommended: treat evictions as not sourceable in PropertyRadar, run the tired-landlord pilot as-is, and line up Death-of-Joint-Tenant as the next segment (it’s the fattest pool and highest ROI).
- Or, if you specifically want the eviction angle, we’d bring in an outside eviction-records source, which is a separate build.

Want me to leave it here, or should I post a short follow-up to the forum confirming the CA eviction-data coverage gap so it’s on record?







|

  • |

VbHA7NKO-k6PSy0qiFtpng

Hello, it is a coverage issue-- certain areas will have more Eviction data available than others, though we are constantly looking to improve our datasets and coverage.

Our coverage pages, a great way to see what we cover for a specific area, will only show the columns for things like “eviction” if there is a % of eviction court records there that hits a larger percentage of the population. So, for instance, North Carolina will show that we have eviction data in a bunch of counties, but California will not.

North Carolina:

California, which has no Eviction column:

There isn’t a way around that, if we do not have a larger dataset available for a particular area, like in your current situation.