Klook

3-letter currency code for prices (e.g. "USD", "HKD", "TWD"). Supported currencies ONLY:SGD, HKD, TWD, ILS, USD, PHP, MYR, CNY, KRW, AED, AUD, CAD, CHF, DKK, EGP, EUR, FJD, GBP, IDR, INR, ISK, JOD, JPY, KHR, LAK, MAD, MGA, MOP, MUR, MXN, NOK, NZD, OMR, QAR, SAR, SEK, THB, TRY, VND, ZAR. Rules:- If the user explicitly asks for a currency and it is in the supported list above, map their wording to the correct 3-letter code and use it. Examples:- "RMB", "人民币" → CNY - "NTD", "台币" → TWD - "港币", "HK$" → HKD - "US dollar", "美金" → USD. - If the user explicitly asks for a currency that is NOT in the supported list(or you cannot confidently map it to one of the supported codes), DO NOT invent a new code. Fall back to "USD". - If the user does not specify a currency: - First infer a reasonable default from userLanguage: - zh_CN → CNY, - zh_HK → HKD, - zh_TW → TWD, - en_SG → SGD, - en_US → USD, - If the inferred currency is not in the supported list for any reason, fall back to "USD".

Maintain the current offset of results viewed by the user in their session for a given search criteria, starting with 0. If the user asks for more results, increment the offset by 1 each time. If the search criteria changes, reset the offset to 0.

The user's original question or request in its complete, unmodified form. This should capture the exact text the user provided without any changes, parsing, or interpretation.

A short search phrase (1–6 words) in the USER'S ORIGINAL LANGUAGE. Destination, category, and preference are all parts of THIS ONE phrase, usually in this order: [destination] [category] [preference] Destination (if given): - If the user mentions a place, the phrase SHOULD start with ONE destination (city / area / country / POI), e.g. "Osaka, Japan", "大阪", "Tokyo Disney". - You may add country to disambiguate if confident, e.g. "London, United Kingdom". - Never include more than one destination in the same phrase. Category (if given): - Only add when the user clearly asks for a type, e.g. "spa", "museums", "food", "spa", "theme park", "shopping". - Generic words like "fun", "有什么推荐", "去哪玩" are NOT categories. - If there is no clear category, just use the destination alone. - If the user does NOT mention any place, but clearly wants a type of activity(e.g. "温泉", "ski resorts", "theme parks"), you MAY build the phrase with only category (and optional preference), e.g.: - "温泉" - "theme parks kids" Preference (OPTIONAL): - Only add preference words if the user clearly states them, e.g. "family", "kid-friendly", "indoor", "outdoor", "romantic", "luxury", "budget". - Never infer preferences from holidays (e.g. Chinese New Year, Golden Week), emojis, or vague phrases like "好一点", "有意思的", "特别一点". Other constraints: - Do NOT include dates, number of people, currency, or time expressions in searchKeywords. - If there is NO clear destination AND NO clear category (e.g. "春节想出去玩", "最近想出去走走，帮我想想？"), do NOT fabricate keywords. Ask a follow-up question first.

Language/locale code inferred from the user's input (e.g. "zh_CN", "zh_HK", "zh_TW", "en_US").This is used to localize the activity results (language of titles, descriptions, etc.).Always match the user's primary writing language in the current conversation. Supported values (whitelist): "en_US", "zh_CN", "zh_TW", "zh_HK", "ko_KR", "th_TH", "vi_VN", "id_ID", "ja_JP", "en_GB", "en_AU", "en_NZ", "en_CA", "en_SG", "en_HK", "en_PH", "en_MY", "en_IN", "en_BS", "fr_FR", "es_ES", "de_DE", "ru_RU", "it_IT", "ar_SA", "ms_MY". Rules: - If the user's writing clearly matches one of the supported locales above, output exactly that code. Examples: - Simplified Chinese → "zh_CN" - Traditional Chinese (Taiwan) → "zh_TW" - Korean → "ko_KR" - English in Singapore context → "en_SG", etc. - If the user’s language/locale is NOT in the supported list, or you are unsure: - Fall back to "en_BS". - If the user mixes multiple languages in one message, choose the dominant writing language.

ISO-formatted booking dates ['YYYY-MM-DD']. Fill ONLY when: - User gives exact dates, e.g. "2026-03-05", "3 月 5 到 7 号". - Or a short, clear relative time (1–3 days), e.g. "tomorrow", "the day after tomorrow", "this Saturday", "this weekend" (use the upcoming weekend). - If current date is before requested month in current year → use current year - If current date is in/after requested month → use NEXT year Leave EMPTY when: - Time is vague or long: "next month", "sometime in March", "春节出去玩", "this summer", "later this year". - In these cases, do NOT guess specific days. Let backend use defaults, or ask for exact dates.