A listing is re-read at its source every week. When the source stops publishing it, it is marked delisted and appears in your removed set. A failed request never removes a listing; only the source does. The rest of this page is what that means in practice and how to test it yourself.
| Field | Meaning | Use it for |
|---|---|---|
first_seen_at | When we first saw the listing at its source. | "New this week" views, days on market, delta ingestion (newSinceDays). |
last_seen_at | When we last confirmed the source still published it. | Your own freshness rule: hide or badge anything older than N days. |
scraped_at | The last successful read of the record, whether or not anything changed. | The window the Display Feed uses: a record must have been read within 30 days to count. |
| delisted | The source no longer lists the unit (delivered as the removed set; never returned by the API). | Remove from display on your next sync. |
Field definitions and types: the docs and openapi.json.
Every source in the feed is read again on a weekly cycle (Sunday). Each unit still on the page is re-stamped; each unit gone from the page is marked delisted. Accounts that come back empty for two cycles are retired as stale.
If a site is unreachable or blocks the read, nothing changes: its records keep their last verified date. Only a successful read that no longer contains the unit removes it. Sweeps run only after a crawl that finished cleanly.
A unit can be leased between two weekly reads. We do not know lease status; we know whether the manager still publishes the listing. Show the last verified date, or hide records older than your own threshold.
Why the displayable count uses a 30-day window and not "everything we hold": rows whose source dropped out of the crawl set are never swept, so "live" would include listings nobody has looked at in months. When we first ran a full verification pass over the banked manager-direct rows (September 2026), about a third were no longer published at their source. None of those reach you.
| Last verified at source | Records | Share | Status |
|---|---|---|---|
| within 7 days | 782,708 | 89.7% | counted as displayable |
| 8 to 30 days ago | 89,725 | 10.3% | counted as displayable |
| 31 to 90 days ago | 26 | 0.0% | held, not counted, not delivered |
| older | 0 | 0.0% | held, not counted, not delivered |
Measured 2026-09-20. Manager-direct sources only. Regenerated with every verification run.
872,433 displayable listings were verified within 30 days, 782,708 within 7. Measured 2026-09-20.
Every delivery comes as three sets so a partial sync is safe: records first seen since your last delivery, records whose fields changed, and records the source stopped publishing. Takedown requests from a source are honoured within seven days and flagged in the feed. Delisted records are never returned by the API.
The checks our own pre-delivery gate runs, in the order a developer usually runs them. Every sample we send has already passed them; the point is that you can confirm it.
url values. Each should load the manager's page with the unit still listed, or show a date in last_seen_at within the last week.image URLs; expect HTTP 200 and an image content type. Photos are by URL, never re-hosted.sqft_min, beds, baths, lat, available, description. Compare with the coverage numbers in the sample email; they should match to the row.property_type takes one normalised set of values; state is a two-letter code; rent_min is a number in currency.scraped_at older than 30 days; first_seen_at present on nearly every record.Field coverage across the feed today: see the table below; your sample carries the exact share for your market.
| url | Source URL the manager's own listing page; attribution and link-back target | nearly every record | |
| rent_min | Rent monthly asking rent, native currency plus rent_usd | most records | |
| street | Street address plus city, state, ZIP; the full string in address | nearly every record | |
| zip | ZIP | most records | |
| beds | Bedrooms 0 = studio | nearly every record | |
| baths | Bathrooms | nearly every record | |
| sqft_min | Size square feet; rent_per_sqft and rent_per_sqm derived | most records | |
| latlng | Coordinates geocoded when the source does not publish them | most records | |
| image | Photo primary image URL; images holds the gallery where the source publishes one | most records | |
| available | Availability date or NOW as published | most records | |
| property_type | Property type apartment, house, condo, townhouse, room, normalised | about half | |
| amenities | Amenities list, as published | about half | |
| description | Description the manager's text; generated boilerplate is removed | about half | |
| first_seen_at | First seen when we first saw the listing at its source | nearly every record | |
| last_seen_at | Last verified when we last confirmed it was still published | nearly every record |
Coverage measured on the current displayable set (Up to 1,000 rows per platform verified 2-30 days ago (so enrichment has run), 22,378 rows over 30 platforms, weighted by each platform's 30-day count.). It varies by source and market; the sample for your geography shows the exact share.
Yes. When the manager's site no longer lists the unit, the next verification marks the record delisted and it appears in the removed set of your next delivery. Removal follows the source, not a timer.
Because a failed request is not evidence. If a site is down or blocks a fetch, its listings keep their last verified date and stay in the feed until they age past the 30-day window or the source is read again. Dropping them on a timeout would remove live units for no reason.
No. Verification is weekly, so a record can have been leased since its last verified date. The feed carries the manager's stated availability date and the timestamps; your product decides how to display recency. Daily verification is available for live partners.
Run the 20-minute checklist on this page against your sample. It is the same set of checks our own pre-delivery gate runs, so what you measure is what we measure. If a number disagrees with what we told you, send it back; the file is the truth, not the email.
We remove the source from the feed and notify licensees in the feed itself; licensees remove the records from display within seven days under the standard terms.
Tell us your cities. The export arrives within one business day with the coverage numbers, and the checklist above tells you whether we told the truth.
Usually within one business day. How pricing works →
You will have the export, the coverage numbers and pricing within one business day.
Twenty minutes on your exact ZIPs, field completeness and how the weekly deltas fit your stack.
Book 20 minutesOr just reply to the sample email.