AI Social API
Updated 2026-09-18 · Chad

A Complaint Thread Can Sit at 10 Replies in a Finance Sub-Forum for Days Before It Reaches the News Desk — Cast an Early-Warning Net Across LIHKG with Multi-Keyword Search

In one line: Plenty of complaint threads on LIHKG — Hong Kong’s largest anonymous discussion forum, roughly Reddit-shaped — start out quiet in a finance or workplace sub-forum, sitting at a dozen or so replies, long before anyone would call it a “front-page” story. LIHKG-scraper’s search mode is already a site-wide title search by design (there’s no sub-forum picker to worry about), so spreading a dozen-plus keywords — brand names, estate names, company names — across a single scheduled run is what actually casts a cross-sub-forum early-warning net.

This post contains Apify affiliate links (no extra cost to you). Costs and comparisons are stated honestly, including where Apify is not the best fit.

The gap between “a dozen replies” and an actual headline

One sub-forum on LIHKG surfaced a complaint: the original poster claimed a customer complaint filed with the Hong Kong Monetary Authority was followed by ZA Bank freezing their account (original thread). This is a single, unverified user allegation — it shouldn’t be treated as fact before the bank or the regulator responds — but it illustrates something structural: these threads start quiet, and they don’t automatically surface in a finance-news feed. If you only read finance headlines, or only scroll a “current affairs” sub-forum, you could easily miss that a thread like this exists at all.

A separate LIHKG thread alleged that owners at Kai Ying Court (啟盈苑) had illegally torn out structural walls during private renovations, and the replies noted the Housing Department said it would follow up (original thread). Independent news reporting later confirmed part of that: the Housing Department carried out a surprise inspection of 9 units and found that 7 had illegally removed the kitchen fire door — but found no evidence of demolished structural walls (The Standard/stheadline, 2026-09-05). Note the mismatch between what the forum thread alleged (structural walls) and what the official inspection actually found (fire doors, not walls) — that gap is exactly the kind of thing a single news read won’t tell you; you only see it by holding both the original allegation and the later official finding side by side.

Our companion piece on tracking a known crisis’s timeline (the Sushiro conveyor-belt apology, and the Chen Xiaodong baseball-stadium fallout) covers what to do once you already know which topic to watch. This piece covers the stage before that — you don’t yet know which keyword is worth watching, because nothing has become a headline yet.

Three real scenarios, three order/maxItems/dateFrom configurations

LIHKG-scraper’s search mode isn’t only good for the early-warning sweep this piece covers — the same mode: "search" call serves three different scenarios, and which order, maxItems, and dateFrom you pick depends on which one you’re in: casting a wide net when you don’t yet know what will blow up, tracking a known crisis’s timeline, or building a dated evidence log for a specific case. Here’s how the three compare:

Early-warning sweep (this piece)Crisis-timeline trackingDeepfake evidence timeline
orderdesc_create_time (lock onto newly-posted threads)desc_reply_time (the sort the input schema itself flags for monitoring)desc_create_time (sort by original post time for a timeline)
maxItemsSmall (e.g. 10, to keep a wide sweep cheap)30 (paired with dateFrom for ongoing tracking of a known topic)100 (pull as much of the relevant discussion as possible for evidence)
dateFromUsually left blank (you don’t yet know the time window)Set (e.g. 3d), paired with desc_reply_time to stop paginating earlyOptional (e.g. 1w, only if you want to track newly-appearing threads)
When to use itYou don’t know yet which topic will blow up; sweep many unrelated keywords to surface candidatesYou already know which topic to watch; track whether the discussion is still climbing or has gone quietYou already have a specific case; build a dated, linkable public-discussion log to support a formal complaint

How to cast a cross-sub-forum early-warning net with LIHKG-scraper

Step 1 — Spread a batch of keywords in search mode; there’s no sub-forum to pick

{
  "mode": "search",
  "keywords": ["brand-name", "estate-name", "company-name", "product-name"],
  "order": "desc_create_time",
  "maxItems": 10
}

Setting mode to search already gives you a site-wide title search (brand names, product names, developer/landlord names) — there’s no sub-forum selector to worry about, because the input schema’s catIds field only applies to list mode (thread-list), where you pick specific sub-forums. keywords accepts up to 50 entries, each queried independently, so a single run can sweep many unrelated candidate terms at once. order: desc_create_time (newest-post-first) locks onto threads the moment they’re posted — that’s a different choice from the crisis-timeline piece’s desc_reply_time, and deliberately so: an early-warning sweep needs “just appeared,” not “still getting replies.” Keep maxItems small (say, 10) to control cost, since the goal at this stage is to cast a net, not exhaustively pull every thread under every keyword.

Step 2 — Re-run the same keyword batch on a schedule

Use Apify’s built-in Schedule feature, or an external scheduler like n8n or cron, to re-run the same keywords set every few hours or once a day. Each run returns the threads currently matching, with fields including thread_id, title, author, reply_count, created_at, thread_url, and scraped_at.

Step 3 — Compare thread_ids across runs to spot new candidates

Any newly-appearing thread_id is a new signal — log it to a tracking list. For the handful of threads you actually decide are worth watching long-term, switch to the method from our crisis-timeline piece: change order to desc_reply_time, add dateFrom (e.g. 3d), and keep comparing reply_count and last_reply_at to see whether the discussion is still climbing or has gone quiet.

Step 4 (optional) — Skip the manual thread_id diff with asia-social-listening

{
  "brandKeyword": "brand-name",
  "searchAliases": ["brand-english-name", "brand-abbreviation"],
  "platforms": ["lihkg"],
  "deltaMode": true,
  "deduplication": true
}

brandKeyword is the one required primary term; searchAliases lets you add up to 10 extra ways of searching for the same brand (an English name, an abbreviation, a common misspelling) — these only apply to the primary brand, not to competitor terms. deltaMode, once enabled, uses a named key-value store to remember mention_id values already seen, comparing automatically across runs so it only returns mentions newer than the last run — no manual list-keeping required. Setting platforms to ["lihkg"] limits monitoring to LIHKG only (this actor also supports monitoring PTT, HardwareZone, and Telegram at the same time, but cross-platform coverage is outside the scope of this piece). Note that this mode is designed around “different ways of naming one brand” — if you’re tracking many completely unrelated candidate terms (different estate names, different company names), the array of up to 50 independent keywords in Step 1 is the right tool for casting a wide net; only once you’ve narrowed it down to the one or two brands you actually need to track long-term does it make sense to switch to this delta-mode setup.

What it actually costs

LIHKG-scraper’s three modes map to three billing events — this piece’s search mode only ever touches search-listing, but mode: "thread" (full-post mode, the method the Su Man Fung/Ming Zai deepfake piece uses for evidence-gathering) touches the other two, so here’s the complete price list in one place:

EventPriceApplies to
search-listing (per thread-list row)$0.002LIHKG-scraper search mode / sub-forum listing mode
product-detail (per thread)$0.008LIHKG-scraper full-post mode (mode: "thread")‘s original post
review-item (per reply)$0.003LIHKG-scraper full-post mode (mode: "thread")‘s replies
mention-aggregated (per deduplicated brand mention)$0.05asia-social-listening

As an example, monitoring 20 keywords with maxItems set to 10 (up to 10 rows per keyword) caps a single run at 200 search-listing events, or $0.002 × 200 = $0.40; actual billing follows the rows genuinely returned, usually below that ceiling. Scheduling every 4 hours (6 runs a day) caps daily cost around $2.4, or roughly $72/month at the ceiling — a reasonable price relative to the alternative of a complaint thread quietly smoldering into a PR crisis before anyone notices. If you instead need mode: "thread" to pull a post and its replies for evidence (as in the Su Man Fung/Ming Zai piece), the cost is product-detail ($0.008/thread) plus review-item ($0.003/reply) — one thread with 50 replies runs about $0.008 + $0.003 × 50 = $0.158. If you later move to asia-social-listening’s delta mode for long-term single-brand monitoring, its per-item price is 25x higher ($0.05 vs. $0.002), which fits a small number of brands you’ve already narrowed down to and need to track continuously — not the initial wide net.

Three ways to start

FAQ

The title says “cross sub-forum” — do I need to set catIds in LIHKG-scraper? No. catIds only applies to thread-list mode, where you pick specific sub-forums. Search mode (mode: search) is already a site-wide title search — you don’t choose a sub-forum, and that’s exactly the point: it hits every sub-forum at once, including ones you’d never have thought to check. That’s where the real cross-sub-forum coverage comes from.

If a keyword gets a hit, does that mean the story is actually going to blow up? No. A keyword match only means the word appeared in a thread title — it says nothing about how serious the situation actually is, and it doesn’t mean the official account of events is true. Complaint threads are often one-sided, and you shouldn’t treat them as fact before an official response. A hit needs a human to read the actual content next; if you also want to judge whether a thread looks like a genuine complaint versus a coordinated word-of-mouth push, our companion piece on using an LLM to tell the two apart covers that layer.

How is this different from the Sushiro/Chen Xiaodong crisis-timeline piece? That piece is for a known single topic you’re already tracking — you pick order: desc_reply_time plus dateFrom and keep watching how reply_count and last_reply_at move on the same thread_id over time. This piece is the earlier, wide-net stage, for when you don’t yet know which topic will blow up — you spread many unrelated keywords, pick order: desc_create_time to catch newly posted threads, and use it to surface candidates. They’re different stages of the same monitoring funnel: use this one to find candidates, then switch to the crisis-timeline method to track the ones that matter long-term.

Do I have to manually diff thread_id lists to spot what’s new? Not necessarily. If you want cross-platform monitoring plus built-in delta mode and deduplication, asia-social-listening does this for you — it uses a named key-value store to remember mention_id values it has already seen and compares automatically across runs, so you don’t have to maintain your own list. The trade-off is a different pricing event at a higher per-item price than a raw search, so weigh that against how much engineering time you have to maintain your own diff logic.

How is this priced? LIHKG-scraper bills under three events: search mode and sub-forum listing mode bill search-listing at $0.002 per thread-list row; full-post mode (mode: thread) bills product-detail at $0.008 per thread for the original post and review-item at $0.003 per reply; all pay-per-event on rows actually returned, no monthly fee. asia-social-listening bills under mention-aggregated, at $0.05 per deduplicated brand mention; repeat mentions of the same thing aren’t charged again.

Is scraping LIHKG legal? We only scrape LIHKG’s public pages, never login-walled data, and we follow the platform’s terms of service and local law.

Further reading


Chad runs 40+ published Apify actors (including the LIHKG-scraper and asia-social-listening used here). Every figure above is checked directly against the linked thread or news report; details that couldn’t be independently confirmed (like a one-sided complaint with no official response) are clearly flagged as unverified allegations, not stated as fact.