Klook Dining Scraper

What does Klook Dining Scraper do?

Klook Dining Scraper scrapes Klook's Food & dining city info for one or more cities, one dataset row per city id.

It talks directly to the same internal API the official Klook Android app uses, reverse-engineered by disassembling the app's native request-signing library and validated against live traffic captured from a real device. No Klook account, no API key. This is the dining slice of Klook All-in-One API, split out as its own focused Actor.

Why use Klook Dining Scraper?

• A genuinely separate subsystem — confirmed live by the parent Actor to use the exact same signing scheme, but talking to a completely different backend (fnbapisrv) from the activities API
• No account needed — works fully anonymously
• Use cases: travel content aggregation for a city's dining scene, feeding a broader travel-guide pipeline

How it connects to the parent

This Actor is a narrow, batch-run spin-off of klook-all-in-one-api (an always-on Standby REST API exposing every Klook endpoint). It reuses the parent's exact, proven request-signing logic (klook-client.ts, copied verbatim, including its signed-POST-body machinery — this endpoint sends a JSON body, not a query string) but only wraps /dining/home, and runs as a normal input-in/dataset-out Actor instead of a Standby API.

Input

Field	Type	Description
cityIds	string[]	Required. Klook city ids, e.g. 28=Tokyo, 29=Osaka.
lngLat	string	Optional "longitude,latitude" string to refine results.

Example:

{ "cityIds": ["28"] }

Output

One dataset row per city id:

{ "cityId": "28", "data": { "...": "food & dining city info" } }

Known limitations

• Requires Apify's RESIDENTIAL proxy group. Klook's edge blocks non-residential IPs with a DataDome bot-challenge page — confirmed directly from this development sandbox (a request byte-for-byte identical to a working one, sent without the proxy, came back as a DataDome JS-challenge HTML page, not JSON). All outbound requests route through Actor.createProxyConfiguration({ groups: ['RESIDENTIAL'] }).
• Local dev smoke testing outside the Apify platform needs "Proxy external access" enabled on the account. This Actor's code was verified to be a byte-for-byte match against the parent's already-published, working klook-client.ts, and the local smoke test run during development failed exactly at the proxy-URL-acquisition step (ProxyConfiguration: The "Proxy external access" feature isn't enabled for your account) — before any request to Klook was even attempted. That's an account-tier restriction on pulling a proxy URL from outside a real platform Actor run, not a defect in this code; once deployed and actually run on Apify's platform, proxy access works through the normal SDK path.
• No dedicated restaurant search/listing endpoint — root-caused by the parent Actor to DataDome, not the request signature. This Actor's /dining/home (city info) is fully working with no session state at all. The app's own restaurant-listing call is protected by a separate bot-detection layer the parent Actor's cracked signing scheme doesn't cover; it's out of scope here too.
• This is an unofficial, reverse-engineered integration, not affiliated with or endorsed by Klook Travel Technology Limited.

Pricing

Pay per event. Charged $0.002 per dining-city (FREE tier) — one event per city id processed. See the Actor's Pricing tab for rates across all tiers.