Wego

Searches for flights between airports or cities. Not for flight status, price tracking, visa information, bookings, or reservation management. Returns results from a Wego metasearch in a single call.

Parameters:

• newSearch: Route (from/to as IATA codes), dates (fromDate, toDate in YYYY-MM-DD), passengers, and cabin class. Omit toDate for one-way trips.
• Defaults when not specified: 1 adult, 0 children, 0 infants, economy cabin.
• filters: Include only when the user mentions specific preferences (airlines, stops, times, price range, etc.).
• sorting: A single string value. Options: score_desc (recommended, default), price_asc (cheapest), duration_asc (fastest), leg1_departure_time_asc/desc (outbound departure), leg2_departure_time_asc/desc (return departure, round-trip only).

Time filtering (time ranges in minutes from midnight, 0-1440):

• Format: {min: minutesFromMidnight, max: minutesFromMidnight}
• Example: "flights after 10pm" → outboundDepartureTimeRange: {min: 1320, max: 1440}
• Example: "depart 8am-1pm" → outboundDepartureTimeRange: {min: 480, max: 780}
• Supports wraparound: {min: 1380, max: 60} = 11pm-1am (crosses midnight)

Refinement: Provide the searchId from a previous response with updated filters or sorting. Refinement replaces all previous filters and sorting entirely — include existing values alongside new ones to preserve them.

Example — changing return to after 10pm while keeping existing airlines ["SQ", "KE"], outbound 6am-8am, and price_asc sorting: { "searchId": "abc", "filters": { "airlines": ["SQ", "KE"], "outboundDepartureTimeRange": { "min": 360, "max": 480 }, "inboundArrivalTimeRange": { "min": 1320, "max": 1440 } }, "sorting": "price_asc" }

Default behavior:

• One date provided → one-way trip
• Return date mentioned → round-trip
• No preferences stated → omit filters
• City name without specific airport → use the city IATA code (e.g., "London" → LON, "New York" → NYC, "Tokyo" → TYO). City codes automatically search all airports in that city.

The widget handles flight result display. Format URLs as markdown links: [text](url).

Searches for hotel accommodations by city, geo-location, or hotel ID. Not for restaurants, activities, car rentals, or non-travel queries. Returns paginated results in a single call. Common city codes (DXB, PAR, SIN, TYO, LON, NYC) can be used directly; use places_find_location for specific hotels, POI coordinates, or ambiguous locations.

Refinement: When changing filters or sorting, provide the searchId from a previous response along with updated parameters. Search type objects are not needed for refinements. Example: { searchId: "abc123", filters: { amenities: ["wifi"], starRating: { min: 4 } } }

Search types (one per new search): 1. citySearch — Hotels in a city. Suitable for generic proximity queries (e.g., "near airports" or "downtown") when combined with sorting. 2. geoSearch — Hotels near a specific location (airport, landmark, POI). Requires latitude and longitude coordinates. Use places_find_location to get coordinates for landmarks. Recommended radius: 10km for landmarks, 20km for airports. 3. hotelSearch — Single hotel by ID.

Children ages: When children are included, their ages affect pricing and availability. Missing or incorrect ages produce unreliable pricing and may return zero results.

Parameter format: All field names are camelCase (checkIn, checkOut, adultsCount, childrenCount). Coordinates go inside the geoSearch object, not as top-level parameters.

Proximity guidance:

• Generic proximity (e.g., "hotels near airport") → citySearch + distance_from_nearest_airport_asc sorting
• Generic city center (e.g., "downtown hotels") → citySearch + distance_from_center_asc sorting
• Named location (e.g., "hotels near Changi Airport") → geoSearch with POI coordinates
• Explicit radius (e.g., "hotels within 15km of Eiffel Tower") → geoSearch with POI coordinates and radius

Integration with places_find_location:

• citySearch: get cityCode with types=["city"]
• geoSearch: get coordinates with types=["poi"]

Examples: New search: { citySearch: { cityCode: "DXB" }, checkIn: "2025-11-06", checkOut: "2025-11-07", rooms: [{ adultsCount: 2, childrenCount: 0 }] } With amenity filter: { citySearch: { cityCode: "DXB" }, filters: { amenities: ["wifi", "pool"] }, ... } Refinement: { searchId: "abc123", filters: { amenities: ["pool"], starRating: { min: 4 } } } Near airports: { citySearch: { cityCode: "SIN" }, sorting: "distance_from_nearest_airport_asc", ... } Near city center: { citySearch: { cityCode: "PAR" }, sorting: "distance_from_center_asc", ... } Near specific airport: { geoSearch: { latitude: 1.3644, longitude: 103.9915, radius: 20, name: "Changi Airport" }, ... } Near specific landmark: { geoSearch: { latitude: 48.8584, longitude: 2.2945, name: "Eiffel Tower" }, ... }

Refinements use the searchId from the previous response with new filters or sorting parameters.

The widget handles image display and presents complete results interactively. Format URLs as markdown links: [text](url).

Optional helper to resolve travel location identifiers for hotels and flights (cityCode, hotelId, airport IATA codes, coordinates). Returns location codes, IDs, and coordinates.

PURPOSE: Provides specific identifiers for other tools:

• Coordinates for hotels_search geoSearch (e.g., "Eiffel Tower" → latitude, longitude) - geoSearch requires coordinates for landmarks
• hotelId for hotels_search hotelSearch (e.g., "Burj Al Arab" → hotelId)
• City code when needed (e.g., "Kota Kinabalu" → cityCode)
• Airport IATA codes when needed (e.g., "New York airports" → JFK, LGA, EWR)

Not for restaurants, shops, recipes, or general non-travel queries.

PLACE TYPES: Filter by specific types using the 'types' parameter:

• city: Major cities (returns cityCode like "DXB", "PAR")
• airport: Airports (returns IATA codes like "JFK", "LHR")
• district: Neighborhoods within cities (returns districtId)
• state: States, provinces, regions
• hotel: Individual hotels (returns hotelId)
• poi: Points of interest, landmarks (returns coordinates)

If 'types' is omitted, returns all matching place types.

POI SEARCH WITH LOCATION BIAS: For POI searches, locationBias (approximate coordinates) can optionally improve result relevance when geographic context is known.

When to provide locationBias:

• User mentions a city: "Eiffel Tower in Paris" (provide Paris coordinates)
• Previous conversation context provides location
• The landmark location is recognized

When locationBias is not needed:

• No geographic context available
• Uncertain about location
• Global/ambiguous landmarks

EXAMPLES: Resolve city: { query: "Kota Kinabalu", types: ["city"] } → cityCode Resolve district: { query: "Downtown Dubai", types: ["district"] } → districtId Resolve airports: { query: "New York", types: ["airport"] } → JFK, LGA, EWR Resolve hotel: { query: "Burj Al Arab", types: ["hotel"] } → hotelId Resolve POI with bias: { query: "Eiffel Tower", types: ["poi"], locationBias: { latitude: 48.85, longitude: 2.35 } } Resolve POI without bias: { query: "Marina Bay Sands", types: ["poi"] }

AMBIGUITY HANDLING: When multiple locations match, response includes hasAmbiguity: true and disambiguationHint. Ask user to specify which location.

NOTES:

• locationBias is optional (text search works without it)
• Approximate coordinates are fine (city-level accuracy)
• Location bias improves relevance but doesn't exclude other regions