Quick answer
Our own QA harness silently clamped maxResults from the prefill's 48 down to 3. The run passed, returned rows, and looked completely green — but it had only ever fetched page one, so pagination shipped untested behind a passing check. We caught it because the harness prints a DEPTH UNPROVEN warning when a run's actual depth falls short of its own prefill, and we fired a deliberate deep run at the prefill's own value: 48 results, charged result: 48 times, pagination proven across pages before this Actor shipped. The Realtor.ca Listings Scraper sells depth — a curated city or bounding box of normalized Canadian listings — so a capped smoke test couldn't be allowed to stand in for proof of it.
Can a "successful" QA run still hide an untested feature?
Yes, and that's the uncomfortable part — success and coverage are two different claims, and a green checkmark only speaks to the first one. A run that exits 0, writes rows to the dataset, and matches its expected schema has proven the code executes without crashing. It has not proven the code executes the path a customer will actually exercise. Here, the harness's own safety clamp — meant to keep smoke tests cheap — quietly capped maxResults at 3 instead of running the prefill's real value of 48. Three results fit on page one of Realtor.ca's api2.realtor.ca search response. The pagination logic that walks page two, page three, and beyond simply never ran, and nothing about the run's exit code said so.
What made this catchable?
A second signal that doesn't just ask "did it succeed" but "did it prove what it's supposed to prove." The harness compares the run's actual depth against the prefill's own stated depth and prints DEPTH UNPROVEN when they diverge — in this case, 3 delivered against 48 promised. That's the difference between a binary pass/fail and a coverage check: it forced the question "did this run test the feature we're charging for," not just "did it crash."
What did the deep run actually prove?
We reran at the prefill's real value — 48 results, no clamp — and the run billed result 48 times and returned distinct listings spanning multiple response pages, confirming the pagination path that page-one-only testing had never touched. A sampled row from that run: a Markham, Ontario condo listed at CAD 990,000, 5+1 bedrooms, with the agent's name and the brokerage's name and address attached — the full shape of what this Actor is built to return, not just what page one happens to contain.
A green run tells you the code ran, not that it ran the feature you are selling. If an Actor's product is depth, a capped smoke test cannot prove it.
What the Actor gives you
One normalized row per listing, deduplicated by id: mlsNumber, price, currency, transactionType, streetAddress, latitude/longitude, propertyType, bedrooms, bathroomTotal, sizeInterior, amenities, photoUrls, agentName, agentPhone, brokerageName, brokerageAddress, listingDetailUrl, plus searchCity, page, and scrapedAt tagging where and when each row was found.
Honest limitations 🚧
One search — one city or bounding box, one transaction type — per run, capped at the server's own 600-result ceiling. Residential listings only; commercial and land property groups are out of scope for v1. No agent email and no listing description text, because Realtor.ca's search response carries neither (we don't emit empty columns pretending otherwise). The curated city list covers 10 major Canadian cities; anywhere else needs an explicit bounding box.
FAQ
Do I need a Realtor.ca account or API key?
No — this reads Realtor.ca's own publicly listed search-result data.
Can I search a custom area instead of a city?
Yes — pass an explicit bounding box (latitudeMax/latitudeMin/longitudeMax/longitudeMin) instead of a city name.
How do you know pagination actually works, not just page one?
We measured it directly: a deep run at 48 results billed 48 result events and returned listings spanning multiple response pages, after our QA harness flagged a shallower run as DEPTH UNPROVEN.
$0.20 per run plus $0.003 per deduplicated listing row — $3.20 per 1,000 results. A zero-match search still succeeds and costs only the start fee.
→ Realtor.ca Listings Scraper on Apify
Built by Devil Scrapes. We rotate residential proxies pinned to Canada, retry with backoff, and — before we call a run "proven" — we check that it actually exercised the depth we're charging for.
Top comments (0)