Despegar

Run a product-card Chappie action (e.g. flight_checkout) and return the checkout URL

Returns round-trip flight deals for destination-discovery requests where the destination is open, multiple, or broader than a specific city. Use this tool when the user wants to discover where to travel and the destination is: - unspecified or "anywhere"; - a country; - a region; - a continent; - a set or category of possible destinations; - otherwise broader than one specific destination city. Do not use when the user has fixed a specific destination city. In that case use the appropriate city-level flight tool according to the user's temporal and pricing intent. `destination_iata_city_codes` accepts both airport and city IATA codes. Airport codes are resolved to their city and duplicate cities are removed. Because of that, when expanding a country, region, or continent, prefer distinct cities over several airports of the same city. For example, do not send both HND and NRT merely to increase destination coverage, because both resolve to Tokyo. When the user names a country, region, or continent, use geographic knowledge to expand it into multiple representative destination cities. Do not collapse a broad geographic request to a single hub. Aim for meaningful geographic and travel-market coverage rather than treating the examples as exhaustive hard-coded mappings. `destination_iata_city_codes=[]` represents an open destination when no geographic destination is fixed. `origin_iata_city_code` accepts a city or an airport code as well; it is resolved to its city the same way the destinations are. A code that resolves to nothing is dropped and the search runs without an origin, so send a code you are confident about rather than a guess. Previous city-level flight results do not prevent using this tool. If the user changes from a specific destination to an open, country, region, continent, or multi-destination request, treat it as a new destination-discovery intent. `months` is an optional array of month numbers (1-12). When the traveller names one or more months, send all of them (e.g. June → [6]; March and June → [3,6]). Do not fill intervening months unless they ask for that stretch (e.g. from March to June → [3,4,5,6]). Omit `months` when no month is named. A follow-up that filters or changes months must call this tool again with the full updated `months` list and the same origin and destinations; do not reuse the previous search without months. Country, region, continent, or open-destination discovery still uses this tool when months are present.

Returns the cheapest available fare for each of the coming months on a route to a specific destination, so the traveller can compare months and choose one before searching concrete flights. TRIGGER: invoke when the message names a concrete destination city and carries no travel date, no date range and no month. Without a travel window there is nothing to quote, so open price, offer, deal and cheap-flight requests for a named city belong here, together with price-behaviour questions such as typical prices, seasonality, or which month is usually cheapest. A currency mention (dollars, USD, euros) does not add a travel window and does not disqualify the request. FLEXIBLE HOUR WITHOUT CALENDAR DATE: a flexible hour preference — "any time of the day", "no preferred departure hour", "at any hour" — is not a travel window. When the message carries one but no departure date, no return date and no month, treat it as absence of travel dates and invoke this tool. DATE GUARD: do not invoke when the message carries a specific date, a date range, or a month. That request already has a search window and is not a trend question, even when it also uses offer or cheap-flight wording. DESTINATION GUARD: do not invoke when the destination is a country, continent or macro-region and no city is named. Inferring a single hub code from a country name does not turn it into a city-level request. REPEAT GUARD: do not invoke again once a price trend already ran in this conversation and the user then asks for concrete options or the cheapest dates inside a named month or period. That follow-up carries a window; carry forward the origin, destination and any filters already established instead of repeating this tool. LOCATION PARAMETERS: `origin` and `destination` are the primary inputs and carry IATA codes — always send both. `origin_name` and `destination_name` carry the human-readable location name; send them whenever the name is known, since they are used to render the answer and to disambiguate the code. City-level codes are the normal case; airport-level codes are also accepted when the user names a specific airport. When the traveller does not state an origin, resolve it per the system-level origin rules; never omit `origin`. When a concrete-search follow-up follows a price trend, carry compatible active user preferences—including stops, baggage, cabin, airline, time-of-day, budget, currency, and ordering—into the next appropriate search tool unless the user changes or clears them, or a prior result marks them dropped or unsupported.

Finds concrete flight options for a specific itinerary with exact travel dates. Use this tool when the user wants actual flight options, availability, or a concrete/bookable price for a specific destination and the required travel dates are exact. For ROUNDTRIP searches, both departure_date and return_date must be exact. For ONEWAY searches, departure_date must be exact and the user or established conversation context must indicate one-way travel. An exact departure date plus an exact stay duration may be converted deterministically into an exact return date when there is no ambiguity. For example, January 5 plus exactly 7 days may resolve to January 12. Do not derive an exact return date from a flexible stay range such as 7–10 days. Flexible months, date ranges, nearby-date requests, flexible stay ranges, or other non-exact temporal constraints belong to flight_flexible_search. `origin_city` and `destination_name` take a location name. A city name and an airport name are equally valid, and there is no need to convert one into the other. Examples of valid location concepts include a city such as "Buenos Aires" or an airport/location such as "Ezeiza". Use the user's natural location expression when appropriate. Do not select this tool merely because the user says "price", "cheap", "offer", or similar language. Exact versus flexible travel timing and the user's complete intent determine the appropriate search tool. PARAMETER PERSISTENCE: When a follow-up changes only some criteria, retain every compatible active user preference from the previous search or any earlier user message, including stops, baggage, cabin, time-of-day, currency, and ordering. Omit a preference only if the user explicitly changes or clears it, or the previous result marks it as dropped or unsupported. Reevaluate whether this remains the appropriate tool. Time-of-day preferences, currency, baggage, airline, cabin, stops, or other filters do not substitute for the required calendar travel date(s). Passenger and minor-age validation follows the system-level rules. Airline parameters have distinct scopes: - `airline`: use when the user wants the same airline restriction/preferences to apply to the itinerary as a whole. For a round trip, it applies to both outbound and return travel. - `outbound_airline`: use when the airline restriction/preferences applies only to the outbound portion. - `inbound_airline`: use when the airline restriction/preferences applies only to the return portion. If the user specifies different airlines by direction, use `outbound_airline` and `inbound_airline` rather than representing one of them as the itinerary-wide `airline`. For example, "Iberia on the way there and Aerolineas on the way back" means outbound_airline=Iberia and inbound_airline=Aerolineas Argentinas. Avoid sending a conflicting itinerary-wide `airline` together with directional airline restrictions. When the user's request clearly distinguishes airlines by direction, the directional parameters represent that intent.

Searches for concrete flight options to a specific destination city or airport when the user's travel timing is flexible or not fully fixed. Use this tool when the user wants actual flight options but provides one or more flexible temporal constraints, such as: - a month rather than exact travel dates; - a travel period or date window; - flexible or nearby dates; - a stay duration; - a stay-duration range; - best or cheapest dates within a period; - a request to move previously exact dates slightly. Do not use when the exact outbound and return dates are fixed for a round trip; use flight-search instead. Do not use for an open destination, country, region, or continent without a specific city/airport destination; use flight-deals instead. This tool needs at least some temporal notion: a month, a period or date window, flexible or nearby dates, a stay duration or stay range, or previously established dates to move. A request that names a destination with no temporal notion at all is not a flexible search — it has no window to search inside — and belongs to flight-price-trend. `origin.name` and `destination.name` take a location name. A city name and an airport name are equally valid, and there is no need to convert one into the other. The date window itself may be left unset when the temporal notion the traveller gave is a stay duration rather than a period. Never invent a date window solely to satisfy the tool. When the user provides a month, relative period, season, explicit date window, or other temporal reference, resolve it relative to the current date. A named period without a year has already passed only when its last day is before today. If today falls inside it, keep this occurrence and start the window today, ending on the period's natural end. Roll the whole period to its next occurrence only when it has fully ended. A period that has not started yet stays in the current year. When previously exact dates become flexible, convert the established exact-date context into an appropriate flexible window and preserve compatible active parameters. If the user specifies the amount of date flexibility, use it. If the user asks to move dates slightly without specifying an amount, the conversation-level default is ±2 days. Preserve established flexible context across follow-ups, including month/date window and stay constraints, unless the user explicitly changes or clears them. Half-fixed trips: when one end of the trip is pinned and the other is still open, send the pinned day in `departure_date` (or `return_date`) together with the stay range, and omit the date window. Only one end may be pinned this way. Stay-duration semantics: - exact N days → stay_days_from=N and stay_days_until=N; - explicit N–M range → stay_days_from=N and stay_days_until=M; - do not convert a flexible stay range into an invented exact return date. If the product defines a policy for open-ended minimum stays such as "at least N days", apply that explicit product policy. Do not invent an arbitrary upper bound unless such a policy exists. When both a date window and stay duration are present, ensure that the window can accommodate the requested stay. If only the stay duration changes in a follow-up, preserve the established travel window. Expand the window only if necessary for feasibility; do not shrink an existing travel period merely to match the stay duration. PARAMETER PERSISTENCE: When a follow-up changes only some criteria, retain every compatible active user preference from the previous search or any earlier user message, including stops, baggage, cabin, time-of-day, currency, and ordering. Omit a preference only if the user explicitly changes or clears it, or the previous result marks it as dropped or unsupported. Passenger, unsupported-filter, and airline behavior follows the system-level rules and the tool schema.

Search for activities available in a destination. Call this tool whenever the user asks to see, explore, discover or search for activities or things to do in a city — no purchase intent or brand mention required. Also call when the user explicitly wants to buy or book an activity. If from_date is later in the year than today, assume current year; if earlier, assume next year.

Helpful to find hotels, apartments, etc. for a given city. Keep the previous search_hotels_on_destination parameters if the user does not mention any specific value, except for any parameters listed in droppedFilters from an ACCOMMODATION_FILTERS entity or description — those are permanently excluded for the rest of the conversation. If the departure date is later in the year than today, assume the current year. If it’s earlier, assume next year. For example, if today is 2024-08-01, and request from 19th of december to 15 of january, december is assumed to be 2024 and january 2025.

Search travel insurance only when destination and both travel dates are known. Never pass empty strings or placeholders. If region_name, region_type, from_date, or to_date is missing, do not call this tool. If the from date is later in the year than today, assume the current year; if earlier, assume next year (example: today 2025-03-05 and request 01–15 March → year 2026). If passenger count is unknown, default passengers to "1".