Product and property data
Parsed JSON for listings, prices and property records
The same machinery as the social catalogue (one billing path, caching, batching, async jobs, change-detecting subscriptions) pointed at commerce and real estate. You never write a selector, and you are never charged for a blocked page.
Sources
What is verified, and against what
Each of these was probed live and parsed a real payload. The evidence is stated rather than asserted, because this is a buyer who will call the endpoint before they finish reading.
Walmart
Productproductcategoryreviews
A real 580 KB product page: title, 219 USD, rating 4.3 over 1,083 reviews. Category paging reported 25 pages and 48 items on the first. Review sorting is honoured rather than merely accepted: asking for newest returned genuinely newer reviews.
Redfin
PropertyListingsearchforSaleforRent
A real 88-home GIS payload. For-sale records carry price, beds, baths, square footage, the listing agent, price history and school assignments.
Zillow
PropertyListingpropertysearch
A real 354 KB property payload: 3,080,600 USD, five beds, five and a half baths, 5,807 square feet, built 2012. Search mapped all 41 rows it returned.
Amazon
Productsearch
Search is verified against a real payload. Product-detail and offers are blocked by an anti-bot challenge and are not claimed here.
Endpoints that a live probe found blocked are not listed above and are not sold. They stay in the reference, marked, because a customer discovering a gap themselves is worse than reading about it here. A blocked page returns upstream_blocked and costs nothing.
One shape
A price is an amount and a currency, never a string
Everyone parses a product page differently, so the same listing arrives in a different shape from every vendor. Here a Walmart product and an Amazon product are the same object, and a Zillow record and a Redfin record are the same object.
The separation matters more than it looks. A page that renders £219 and a page that renders 219,00 € both mean a number and a currency, and flattening either into a string moves the problem to whoever consumes it, usually after they have already compared two of them.
A live probe produced the failure this design prevents: a well-formed product, HTTP 200, and the wrong product, because the request had silently exited through the wrong country. Amount and currency as separate fields is what makes that detectable rather than plausible.
{
"platform": "walmart",
"id": "18210919718",
"title": "…",
"price": { "amount": 219.00, "currency": "USD" },
"rating": 4.3,
"reviewCount": 1083,
"availability": "in_stock",
"fetchedAt": "2026-09-04T18:11:07.402Z"
}Watching
Watch a listing, and hear only when it changes
A watch checks one listing on a schedule and sends a signed webhook when the data actually changes. Each check is charged at the endpoint's normal price, and a check that fails or comes back empty is refunded. You pay for the checks, and hear from us only when something moved.
A change is any difference in the returned record, not only the price: a new review moves a product's review count, and that counts. Fields that differ on every fetch, such as the fetch timestamp, are ignored, so a listing that has not moved stays silent.
The shortest interval is one hour. Search and category results cannot be watched: they return a different result set from one request to the next, so every check would count as a change and fire the webhook. Watch the listings themselves instead.
If your team runs out of credits, checks are refused rather than charged, and after the second refused check the watch pauses. Top up and it picks back up on its own at its next scheduled check.
Watchable on this page
- walmart.product
- walmart.reviews
- redfin.forSale
- redfin.forRent
- zillow.property
Read from the live API reference, so this is what the API accepts as a watch today.
Call one and see.
Every endpoint publishes its credit cost in /openapi.json, so an agent can work out what a call costs before it makes it.