We check listings at their source each week. A successful check that confirms a listing is gone marks it delisted. A failed request does not count as a delisting or reset the verification date. Records also leave delivery when they exceed the freshness limit or a source requests a takedown.
| 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. | Operational history; published coverage counts records verified within seven days. |
| 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, its records keep their last verified date. A successful read can confirm a delisting; an unresolved record is excluded from delivery once its last verification is more than 30 days old.
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.
Published coverage uses a seven-day measurement window. The standard delivery policy has a separate maximum age of 30 days from the last successful verification. This is a freshness limit, not a guarantee that a listing remains available.
Coverage pages count only records verified at their source within seven days. Each count is dated and refreshed with the weekly measurement.
A failed check is not a delisting and does not reset the last verification date. A record stops contributing to published coverage once that date falls outside seven days.
The standard delivery policy excludes records more than 30 days past their last successful verification. Confirmed delistings leave on the next sync.
The current seven-day inventory count and measurement date are on Coverage. Measured 2026-11-03.
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.
HousingFeedurl 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 within seven days of the measurement date. Check your delivered records against the freshness window agreed for your feed.See field coverage across the seven-day sample. Your sample shows the populated fields for your market.
Every source in the feed is re-read on a weekly cycle. A listing still on the manager's page keeps its last-verified date; a listing gone from the page is marked delisted. A failed request changes nothing.
The status of a record whose source no longer publishes it, confirmed by a successful read. Delisted records are delivered in the removed set of your next delivery and are never returned by the API.
The three timestamps on every record: when the listing was first observed at its source, when the source was last confirmed to publish it, and when the record was last read. They let a product apply its own freshness rule.
The standard delivery policy excludes records more than 30 days past their last successful verification. Published coverage uses a narrower seven-day window. Neither is a statement about whether a unit is still available to rent.
Yes. A successful source check that confirms a listing is gone marks it delisted for removal on your next sync. Records also leave delivery if they exceed the freshness limit or a source requests a takedown.
Published coverage counts only records verified within seven days. Delivery has a separate maximum age of 30 days from the last successful verification. A failed check does not prove that a listing disappeared or reset that date. Records older than seven days do not contribute to published coverage.
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 timestamps; your product decides how to display recency.
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.
You will have the records, the coverage numbers and pricing within one business day.
Twenty minutes on your exact ZIPs, field coverage and how the weekly deltas fit your stack.
Book 20 minutesOr just reply to the sample email.