Klook Destination Guide Scraper

What does Klook Destination Guide Scraper do?

Klook Destination Guide Scraper takes one or more Klook destination (city) ids and pushes each city's full destination guide — share info, i18n city name, and every content tab (Highlights, Attractions & landmarks, Hotels, Deals, Food & dining, ...) — plus its trending points-of-interest list, one dataset row per destination 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 destination-guide slice of Klook All-in-One API, split out as its own focused Actor.

Why use Klook Destination Guide Scraper?

• Two calls in one row — the full city guide and its trending points of interest, fetched in parallel and merged into a single dataset item per destination id
• A dedicated city-guide screen, not a search filter — confirmed live by the parent Actor: tapping a city from Klook's Trending destinations rail fires this exact endpoint, distinct from /search with a city filter
• Rich per-POI descriptions — trending sights come with their own long-form description and tags, plus related bookable activities, not just a title/image
• No account needed — every read request works fully anonymously
• Use cases: destination-guide content aggregation, city landing-page generation, points-of-interest enrichment for a travel app

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) but only wraps /destinations/{id} and /destinations/{id}/trending-sights, and runs as a normal input-in/dataset-out Actor instead of a Standby API.

Input

Field	Type	Description
destinationIds	string[]	Required. Klook destination/city ids (same id used elsewhere as city_id), e.g. 28=Tokyo, 29=Osaka.
includeTrendingSights	boolean	Also fetch each destination's trending points-of-interest list. Default true

Example:

{ "destinationIds": ["28", "29"] }

Output

One dataset row per destination id:

{
    "destinationId": "28",
    "guide": { "...": "full destination guide (share info, i18n name, content tabs)" },
    "trendingSights": { "...": "trending points of interest, each with a description and tags" }
}

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 search/discovery of destination ids here — use klook-search-scraper or /search/init's trending destinations to find ids first.
• 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 destination (FREE tier) — one event per destination id processed. See the Actor's Pricing tab for rates across all tiers.