What are the asterisks in Crexi's data, and what do you do with them?

Crexi puts some listing attributes behind its own paywall, and instead of leaving them empty it returns a string of asterisks: 'Year Built': '****', 'APN': '********', 'Cap Rate': '*******'. Over 12 retail listings sampled on 2026-09-07 that happened on 9 of the 9 listings that carried Year Built, 6 of 6 for APN, and every occurrence of Cap Rate, Parking, Tenancy, Units, Beds, Net Rentable and Price per SqFt. This Actor drops them, so a field is either a real published value or absent. It matters more than it sounds: '****' is a non-empty string, so it passes an is-not-null filter, sorts as text, and quietly ruins any count of how complete your data is.

How many listings can one search return?

Up to 1,499 per location, and that ceiling is Crexi's rather than ours — the API rejects any request where offset plus count reaches 1500. The catalogue held 242,488 listings on 2026-09-07, and a single city can exceed the window: Austin matched 2,367 with no type filter. When a search matches more than can be paged, the run returns a free row saying how many matched against how many were reachable, so you know to narrow by property type, city or price band rather than assuming you have everything.

Can I filter by price, or by lease versus sale?

Price yes, lease-versus-sale no. Crexi's API accepts askingPriceFrom and askingPriceTo and then ignores them — with or without a band the match count is identical — so price is filtered here, on the values actually returned. Its isLease parameter behaves the same way, and rather than offer a switch that silently does nothing, this Actor does not have one. Setting any price band excludes listings marketed without a published price, since 'call for offers' cannot satisfy a band.

Do I get broker email addresses and phone numbers?

No, and no Crexi scraper can give you them from this API — the broker endpoint publishes a first and last name, the brokerage, a headshot, a public profile id and a listing count, and no contact fields at any tier. What you get is the broker's name, their brokerage, a link to their public Crexi profile and how many listings they currently hold, which is enough to identify and rank who is active in a market. Anything advertising CRE broker emails is getting them from somewhere other than here.

Which property types can I search?

Crexi's own eleven, spelled its way: Land, Retail, Office, Industrial, Multifamily, MixedUse, SpecialPurpose, Hospitality, SelfStorage, MobileHomePark and SeniorLiving. Their live counts on 2026-09-07 were Land 118,855, Retail 57,038, Office 38,854, Industrial 29,049, Multifamily 28,964, MixedUse 22,304, SpecialPurpose 15,999, Hospitality 5,711, SelfStorage 2,367, MobileHomePark 1,097 and SeniorLiving 838. A value Crexi does not recognise is rejected by Crexi with an error, so this Actor checks first and returns a free row naming the valid ones rather than failing the run.

What happens if Crexi is down or changes its response?

You get one free, unbilled row saying so — notice_type 'blocked' for an outage or refusal, 'source_changed' if the response no longer carries the result envelope this Actor reads. That distinction is the point: a commercial-listing scraper that starts returning nothing still completes as a SUCCEEDED run, so nothing on the Store's own failure rate can reveal it, and 'the source moved' and 'there are no listings here' look identical in a dataset unless one of them says which it is.

Do the coordinates come from Crexi or from a geocoder?

From Crexi. Latitude, longitude and county are on its own listing record, so every row carries a point the source itself published rather than one derived from an address string. That matters for mapping: a geocoded address can land on a street centroid or a city centroid and still look plausible.

How do I get only listings that are new since my last run?

Every row carries activated_on, the date Crexi made the listing live, and updated_on for its last change. Run on a schedule and filter on activated_on downstream. Rows carry Crexi's own stable listing id, so de-duplicating between runs is exact rather than address matching.

Do I pay per location or per listing?

Per listing returned. Submitting ten cities that hold 1,000 listings between them costs the same as one city with 1,000. The result cap applies per location rather than per run, so a busy city cannot use up the run and leave the others looking empty. Detail and broker enrichment add one request each per listing but no extra charge, and marker rows are free.

No. Crexi's search API answered a plain client in about 0.24 seconds from an ordinary connection, so the proxy input is off by default and enabling it only adds latency.

Use case

Building a County-Level Commercial Inventory Map from Crexi

Every commercial listing in a set of markets, with county, coordinates and asking price on each row — and how to sweep past Crexi's 1,499-result paging ceiling.

“What is for sale in this market, and where?” is a question you cannot answer from a listing site one page at a time. You need every listing in the geography as rows, with a coordinate, a price and — where Crexi states one — a county, so you can put them on a map, group them, and see where inventory is concentrated and what it is asking.

Crexi publishes all of that. The work is getting it out in bulk, and the one thing that will quietly ruin your dataset if you do not plan for it is a paging ceiling.

The ceiling, and how to sweep past it

Crexi refuses any search where offset plus count reaches 1500. That is the platform’s limit, not a setting — so no single search can return more than 1,499 listings, out of a catalogue that held 242,488 on 7 September 2026.

That is easy to trip over without noticing. On the same day, “austin texas” with no property-type filter matched 2,367 listings: a single mid-sized metro already exceeds the window. A sweep that looks like it finished would have silently held about 63% of the city.

The fix is to slice the search until each slice fits, and the natural slices are the ones you probably want as columns anyway — geography and property type. Crexi’s eleven types and their live counts on 7 September 2026:

Type	Listings
`Land`	118,855
`Retail`	57,038
`Office`	38,854
`Industrial`	29,049
`Multifamily`	28,964
`MixedUse`	22,304
`SpecialPurpose`	15,999
`Hospitality`	5,711
`SelfStorage`	2,367
`MobileHomePark`	1,097
`SeniorLiving`	838

So rather than one broad sweep, run city × type and let each one come back well inside the window:

{
  "queries": [
    "austin texas",
    "san antonio texas",
    "houston texas",
    "dallas texas"
  ],
  "types": ["Retail"],
  "maxResults": 1499
}

maxResults applies per location, not per run, so four cities can each return up to their own cap. That detail is the difference between four complete markets and one complete market followed by three that look empty.

You do not have to guess whether a slice fit. When a search matches more than can be paged, the run returns a free row saying how many Crexi matched against how many it could reach — so a truncated sweep announces itself instead of looking like a finished one.

What each row gives you for the map

{
  "listing_id": "2661656",
  "name": "6229 Old Lockhart Road",
  "property_types": ["Retail", "Industrial", "Land"],
  "status": "On-Market",
  "asking_price": 650000.0,
  "city": "Buda",
  "county": "Travis County",
  "state": "TX",
  "zip": "78610",
  "latitude": 30.0733165,
  "longitude": -97.7213696,
  "brokerage_name": "John B. Sanford Real Estate",
  "activated_on": "2026-08-13T18:35:24.429Z",
  "market_url": "https://www.crexi.com/properties/2661656/texas-6229-old-lockhart-road"
}

county, latitude and longitude come from Crexi’s own listing record. Nothing is geocoded here from an address string, which matters for exactly this use case: a geocoder handed “6229 Old Lockhart Road” with no ZIP can land on a street centroid, or the middle of the city, and the pin will look entirely reasonable while being wrong. Taking the point the source published avoids the whole class of problem.

One caveat before you group by it: county is not on every listing. Across 40 Austin retail listings checked on 7 September 2026 it was present on 33 — Crexi simply does not state it on all of them. city, state and the coordinates were on all 40, so if you need every row to land somewhere, group on city or derive the county from the coordinates yourself.

Note also that property_types is a list. A property can carry several — the row above is Retail, Industrial and Land at once — so grouping by “type” means deciding whether a mixed listing counts once or several times. Crexi’s own totals count it in each.

Grouping it

With those columns, the analysis is ordinary spreadsheet work:

Inventory by county — count rows grouped by county.
Price bands — bucket asking_price, remembering that null is a real answer (“call for offers”) and not a gap. Setting minPrice or maxPrice on the run removes unpriced listings entirely, so leave them empty if you want to count them.
Newest first — sort on activated_on, the date Crexi made the listing live. Run the same input weekly and diff on listing_id to get what came to market since last time; the ids are Crexi’s own and stable, so the diff is exact rather than address matching.
Who is marketing it — brokerage_name is on every row without enrichment. Turn on includeBrokers to get the individual broker, their profile link and how many listings they currently hold, which is a reasonable proxy for how active they are in that county.

What it costs

$0.003 per listing. A four-city retail sweep returning 1,000 listings is $3.00. A run that matches nothing, or that tells you it was truncated, costs nothing.

What this will not give you

Broker email addresses and phone numbers, because Crexi’s API publishes neither at any tier — the broker record is a name, a brokerage, a public profile and a listing count.

And a set of listing attributes that Crexi keeps behind its own paywall: Year Built, APN, Cap Rate, Parking, Tenancy and Units among them. Those come back from Crexi as strings of asterisks rather than as empty values, and this actor drops them rather than passing **** through as though it were data. If your model needs cap rates, this is not the source for them.

If you only need a handful of comps in one submarket, Crexi’s own site is free and faster than any of this. The bulk route earns its place when you want several markets, kept current, in a form you can join to your own data.

The full how-to guide covers the rest of the input, including the detail enrichment and what the run log tells you when a sweep is truncated.

The actor itself — Crexi Commercial Real Estate Listings & Broker Scraper — lists its live health, its nightly canary record and its current price.

For the residential side of the same map, the Zillow & Redfin Property Scraper covers individual addresses rather than what is for sale across a market.

Last updated 2026-09-07