Hong Kong Rental Agent Gone Silent? Track ricacorp-scraper's price_changes/updated_at to Tell a Dead Listing From a Slow Agent
In one line: Sending a Hong Kong rental agent everything they asked for and then hearing nothing back isn’t a rare complaint. But checking a listing once only tells you whether its details are accurate — it can’t tell you whether it’s still worth waiting on. Schedule ricacorp-scraper to re-pull the same batch of listings and track how
updated_atandprice_changesmove across runs, and you can see for yourself whether a listing is still being actively managed.
You send everything they asked for, then silence
A renter in Hong Kong described this on Threads: after contacting several rental agents and providing exactly what each one asked for — proof of income, preferred move-in date — every single one went quiet. No callback, not even a one-line “nothing suitable right now.” The post left the renter wondering whether they’d made some mistake in the process, or whether something was off with the listings themselves. It struck a chord — 4.5K views and 21 comments from people who recognized the pattern.
There’s no way to check directly whether an agent personally read your message and chose not to reply — that part stays unverifiable. But one adjacent thing is checkable: whether the listing record itself is still being maintained while you wait. Is That Hong Kong Listing Actually For Sale? covers the question you’d ask before contacting an agent — does the posted deal_type and asking price match what they told you. This piece covers the question that comes after — while you’re sitting in the silence waiting for a reply, how do you tell, objectively, whether it’s still worth waiting.
A single check and scheduled tracking answer different questions
| Single check (listing accuracy) | Scheduled tracking (this guide) | |
|---|---|---|
| Question it answers | Does the posted listing match what the agent told you | Is this listing still being managed, or has it gone quiet |
| When to use it | Right after you get a listing/link, before contacting the agent | During the wait, after you’ve already reached out |
| How often to run it | Once | Repeatedly on a schedule (e.g. daily or every other day) |
| Fields to watch | deal_type, price_hkd | updated_at, price_changes, whether post_no disappears between runs |
How to schedule ricacorp-scraper to track a single listing
ricacorp-scraper currently offers only a search mode — there’s no detail mode to pull one record by listing ID, and no keyword or estate-name search parameter either. The only filters are regions (Hong Kong Island / Kowloon / New Territories East / New Territories West) and rooms. To track one specific listing, you schedule the same search conditions repeatedly, pull the full batch each run, and find your target inside the output yourself using post_no (or listing_url).
Step 1 — Take a baseline snapshot
{ "mode": "search", "dealType": "rent", "regions": ["Kowloon"], "maxItems": 200 }dealType: "rent" returns rental listings (Ricacorp’s own input schema page puts the rental set at roughly 5,900 listings). Note that maxItems is a combined cap across all regions, not a per-region one — if the district your target listing sits in has a lot of inventory, setting maxItems too low means you risk missing that one record and misreading it as “delisted” later.
Once the run finishes, find the listing you’re tracking by its post_no (agents’ links to a listing usually include it, in a format like CU88487564) and record its updated_at and price_changes (any logged price cuts) as your baseline.
Step 2 — Put it on a schedule in Apify Console
Use the Schedule feature on the actor’s page in Apify Console: set a cron expression (say, once a day) and it reruns the same input on that timer automatically — no need to write scheduling logic or keep a server running yourself.
Step 3 — Compare across runs to tell “delisted” from “just not updated”
After each scheduled run, look up the same post_no again:
- Not found at all: this listing is no longer in Ricacorp’s current active set — it may have been let, taken down, or pulled by the agent.
- Still present, but
updated_atandprice_changesare unchanged: the listing is still live, but hasn’t been touched during that window. If this holds across several consecutive runs, both the listing and the agent handling it have been fairly static during that stretch. price_changesgained a new entry (with achanged_attimestamp): the agent is actively managing this listing and adjusting the asking price — it’s still live and moving.
What this method can’t do — updated_at/price_changes reflect whether the listing record itself has been updated, not whether the agent has read your message, and they can’t prove you’re being deliberately ignored. But if the listing itself has sat untouched for a stretch, it’s at least an objective input for deciding whether “nobody’s managing this listing” versus “I’m just the one person who got dropped” — worth weighing alongside everything else, not treating as the final word.
Want to go further: is the whole district quiet, not just this listing?
If you want to know whether it’s just this one listing that’s gone quiet, or the whole estate/district has seen little real activity lately — making it genuinely hard for any agent to bring you something new — schedule centaline-scraper’s transactions mode to track actual completed deals in the same estate (official Store page):
{ "mode": "transactions", "keywords": ["Taikoo Shing"], "dealType": "rent", "dateFrom": "14d", "maxItems": 30 }How dateFrom works is covered in Is That Hong Kong Listing Actually For Sale?; rerunning this on a schedule and only picking up new transactions tells you whether deals are actually closing in that estate during your wait. Centaline and Ricacorp are separate, independent agencies — their estate naming and property IDs don’t line up one-to-one, so this only gives you a rough district/estate-level cross-check, not a listing-by-listing match. For more on pairing transactions mode with Centaline’s own ccl city index mode, see Hong Kong’s CCL Index Is Up 12% in 2026.
What it actually costs
Both actors run on pay-per-event (PPE) billing and use the same search-listing event at $0.002 per item (ricacorp-scraper pricing, centaline-scraper pricing):
| Action | Items per run (example) | Cost per run |
|---|---|---|
| ricacorp-scraper search (one region, rentals) | 200 items | $0.4 |
| centaline-scraper transactions (one estate, last 14 days) | 30 items | $0.06 |
Scheduling ricacorp-scraper once a day to track the same batch of listings runs roughly $12/month (about 30 runs); narrowing to a single district and dropping maxItems (say, to 50) brings that down considerably further.
Three ways to start
From least effort to most freedom
FAQ
ricacorp-scraper doesn’t have a detail mode — how do I track one specific listing? The actor currently offers only a search mode; there’s no way to pull a single record by listing ID. The workaround is to schedule the same regions/dealType search repeatedly, pulling back the full batch each time, then find your target listing’s post_no (or listing_url) inside each run’s results and compare its updated_at and price_changes across runs.
What’s the difference between updated_at and price_changes? updated_at is the timestamp of the last time this listing record was updated upstream — any field change can bump it. price_changes is an array that logs price changes specifically; a new entry only appears when the asking price actually moves, and each entry carries the before/after amount and timestamp. A listing with no price changes shows price_changes as null, but updated_at can still move because of unrelated field updates (tags, photos, and so on) — the two signals aren’t interchangeable, and you need both.
How do I know if a listing has actually been pulled, versus just not updated? If the post_no you’re tracking is completely absent from a later scheduled run’s results, that record is no longer in Ricacorp’s current active listing set — it may have been let, taken down, or pulled by the agent. If it’s still present but updated_at and price_changes haven’t changed across several consecutive runs, the listing is still live but hasn’t been touched. Make sure maxItems and the regions you filter on are wide enough, or you’ll misread a listing you simply failed to fetch as “delisted.”
How do I schedule an Apify actor to run automatically? Use the Schedule feature on the actor’s page in Apify Console: set a cron expression (for example, once a day) and it reruns the same input automatically on that timer — no need to write your own scheduling logic or keep a server running.
Can this method prove an agent is deliberately ignoring you? No. This method can only tell you whether the underlying listing record itself has been updated — it can’t tell you whether the agent has actually read your message, or whether you’re simply the one person they’ve dropped. But if the listing itself has stayed untouched for a while, that’s an objective data point for deciding whether to keep waiting — not proof of intent, and not the only thing worth checking.
Related reading
- Is That Hong Kong Listing Actually For Sale?: that piece checks a listing before you reach out to the agent; this one covers the wait after you already have.
- Hong Kong’s CCL Index Is Up 12% in 2026: for pairing
centaline-scraper’stransactionsmode with its citywidecclindex mode, if you want to check district-level activity beyond a single listing.
Chad runs 40+ published Apify actors, including ricacorp-scraper and centaline-scraper used here. Every field definition and pricing figure above is cross-checked against each actor’s own Store page and input schema; claims that couldn’t be sourced aren’t in this article.