check_restaurant_availability
ChatGPTREQUIRED STEP before booking a restaurant. Probes SevenRooms first, then Servme, for reservation availability. You MUST call this BEFORE get_payment_link_for_non_seated_event whenever get_event_details returned is_restaurant=true. Skipping this step will produce a checkout that the restaurant rejects when a reservation platform is configured. When to call: right after get_event_details returns is_restaurant=true. First let the user PICK a day from the available_dates_display list on the details result and ask for party_size (number of guests); do NOT ask them to type a date, and do NOT invent or default either value. A picked day is the same index in available_dates, which already holds the ISO string. Then call this tool. Outcomes: 1. not_sevenrooms=true → the restaurant is on neither SevenRooms nor Servme. Use the standard ticket flow. Proceed to get_payment_link_for_non_seated_event with restaurant_availability_checked=true (and no seven_rooms_details / servme_details). The flag tells the server-side gate you already ran availability so it lets the booking through. SEATING AREAS (SevenRooms only): the response lists the restaurant's seating areas under table_areas (e.g. Indoor, Terrace). When there is more than one and the user has not named a preference, present the area names and let them pick, then re-call with table_area=<the chosen name> to get that area's times. Omitting table_area searches every area at once. Servme restaurants have no areas. 2. available_times is a non-empty list → a reservation platform is configured. Present the times to the user (each entry has name + time_display + shift_name). When the user picks a time, look up that entry and call get_payment_link_for_non_seated_event with EITHER: • seven_rooms_details = {party_size, date, time, shift_persistent_id, access_persistent_id} when the entry carries shift_persistent_id + access_persistent_id (SevenRooms), OR • servme_details = entry.servme_details copied VERBATIM when the envelope has platform='servme' and the entry carries a servme_details block. Do NOT also set restaurant_availability_checked in this branch — the detail block already satisfies the gate. CRITICAL: use entry.time (HH:MM:SS) NOT entry.time_display; pass IDs exactly as returned — never invent them. 3. error='auth_required' → the reservation endpoint requires the user to be signed in to webook. Call start_webook_login to hand the user the sign-in link, STOP the turn, then retry check_restaurant_availability with the same args after they sign in. Use this when: get_event_details returned is_restaurant=true and you have the user's reservation date + party size. If it returns error='auth_required', call start_webook_login to hand the user the SSO link, stop the turn, and retry with the same args once they're signed in.. Do not use for: non-restaurant items, or when date / party_size haven't been collected from the user yet.
check_time_slot_capacity
ChatGPTList the bookable time slots for a date of a time-slotted event. Call this BEFORE generating a payment link for events with time slots. Pass time_slot as the ISO date (YYYY-MM-DD) the user picked from the event's available dates. The returned time_slots are only the bookable ones — sold-out slots are already filtered out. Each entry carries time_slot_id, time_from/time_to, available, spots, and valid_ticket_ids — the ONLY ticket ids bookable for that slot; other tickets will be rejected at checkout. If the requested date has nothing, the server auto-advances to the next date with inventory and the response's date says which. If time_slots is empty, follow the returned instruction. After the user picks a slot, call get_slot_tickets with its time_slot_id. Use this when: an event has time slots and you need the bookable slots for a date before payment link generation. Returned slots are pre-filtered: sold-out slots are removed and valid_ticket_ids are the only bookable ticket ids per slot.. Do not use for: events without time slots.
checkout_flight
ChatGPTGenerate a payment link for the flight booking. This tool is called by the widget checkout form — do NOT call it directly. The widget collects email and phone from the user and calls this automatically. Use this when: checkout contact details are known and payment link generation is required. Do not use for: manual invocation before checkout context is prepared.
checkout_hotel
ChatGPTComplete the hotel booking and generate a payment link. Required inputs: hotelReservationId from select_hotel_package, and the guest's first_name, last_name, email, phone country/area_code (e.g. '966', without a leading +), and phone number. Empty strings are rejected by the upstream API. For a multi-room stay pass the same rooms array used for the search, plus optionally guests — the lead guest for each room, in room order (omit it to book every room under the primary guest). Returns a payment link the user opens to complete the booking. Use this when: traveler/contact details are collected and hotel payment link must be generated. Do not use for: before select_hotel_package returns hotel_reservation_id.
get_event_addons
ChatGPTCall this ONLY when get_event_details returned has_addons=true. Returns the catalog of optional add-ons (food, accessories, extras) available for this event and ticket set. REQUIRED arguments: event_id (24-char _id from get_event_details), event_ticket_ids (JSON array of ticket _id values from event_tickets[]). After the user picks add-ons, forward them into the payment-link tool as addons=[{"id": <addon _id>, "qty": <int>}]. Use the 24-char _id of each addon from the response — never names. Use this when: get_event_details returned has_addons=true and the user should be offered optional extras before the payment link is generated. Do not use for: events where get_event_details did not set has_addons=true.
get_event_details
ChatGPTDO NOT call this tool automatically after a search. The search result already renders as an interactive card the user can inspect on their own. Only call this tool when the user has EXPLICITLY picked one of the results and asked to see its details OR asked to book it (e.g. 'tell me more about #2', 'show me the ticket options for Sadelle's', 'book the first one'). A single restaurant/event returned from search is NOT a selection — wait for the user's turn. Once the user has selected: this is a REQUIRED STEP before booking. Fetch full details for a specific event/restaurant by slug. Returns ticket categories, prices, and booking flags (is_seated, has_time_slots, is_restaurant). If the event has a queue, the response will contain queue position info instead of event details — tell the user their queue number and offer to refresh. When the queue clears, the full details are returned. After getting details, analyze the response to determine the booking path: - If is_restaurant=true → the tool automatically probes SevenRooms and, when configured, returns `available_times alongside the event details (using reservation_date / party_size if you passed them, otherwise today + party_size=2 as a preview). Present the returned available_times to the user, then book with seven_rooms_details from the picked entry. If not_sevenrooms=true, use the standard non-seated checkout with restaurant_availability_checked=true. If you already know the user's date/party, pass reservation_date (YYYY-MM-DD) and party_size so the times match their intent. - If is_seated=true → use get_payment_link_for_seated_non_timeslot_event. - Otherwise → use get_payment_link_for_non_seated_event. In BOTH cases, if has_time_slots=true, first run the slot flow (check_time_slot_capacity → get_slot_tickets) and pass the picked time_slot_id to the payment tool. Seating selects the tool; time slots only add a step. NEVER redirect the user to the website to select seats. Pass image_url from the search results (image11.url) so the details widget can display the event image. Use this when: the user selected one event and you need booking flags and tickets. Do not use for: broad discovery (use search_webook); items returned from search with type: "halayalla_experience" — use get_halayalla_experience_ticket_details` instead, they're not on api.webook.com.
get_flight_fares
ChatGPTFetch available fare tiers (e.g., Light, Value, Plus) for a selected flight. Each fare has different pricing, baggage allowance, and change/cancellation policies. Call this after the user selects a flight from search results. Use this when: a flight is selected and you need fare tiers before final selection. Do not use for: initial flight search.
get_halayalla_experience_payment_link
ChatGPTGenerate a checkout/payment link for a Halayalla experience via the email-based Hold AI endpoint. This does NOT confirm the booking — the user must complete payment first. REQUIRED arguments: user_email, event_id, event_slug, facility_id, num_of_people. EMAIL: Before calling this tool you MUST collect the user's real email address in chat ("What email should we use for the booking confirmation?"). Pass it as user_email. NEVER invent, guess, or use placeholders. No sign-in is required. IDs: event_id MUST be the 24-char hex MongoDB _id from get_halayalla_experience_ticket_details — NOT the slug. facility_id MUST be the 24-char hex _id of the chosen facility — NEVER the facility name or label. event_slug is the URL-style identifier. Do NOT pass payment_method, facility, facility_name, price, date, time_from_ts, time_to_ts, time_slot_mode, amount, actual_amount, or any other legacy parameters — they are ignored. Returns a payment link the user opens to complete the booking. Use this when: facility, date, slot timestamps, and attendee count are finalized. Do not use for: before collecting a concrete slot and pricing payload.
get_halayalla_experience_ticket_details
ChatGPTREQUIRED STEP before booking a Halayalla experience. Fetch ticket and time-slot details for a Halayalla venue experience by slug. Returns available facilities, time slots, and prices. After calling this, ask the user for date, time and number of people, then call get_halayalla_experience_payment_link. Never ask how the user will pay — they choose that on the webook payment page. Use this when: the user selected a Halayalla experience and needs ticket/time-slot options. Call this for any search_webook result item whose type is halayalla_experience — these live on app.halayalla.com, so get_event_details (api.webook.com) will not return their tickets.. Do not use for: standard events or seasons.
get_halayalla_experience_ticket_details_by_date
ChatGPTFetch ticket and time-slot availability for a Halayalla experience on a specific date (YYYY-MM-DD). Use this when the user specifies a preferred date to see what's available before booking. Use this when: the user gave a specific date and you need date-filtered Halayalla availability. Do not use for: date-agnostic discovery.
get_hotel_details
ChatGPTFetch detailed information for a specific hotel including description, location, check-in/out times, amenities, and images. Call this after the user selects a hotel from search results. Use this when: the user selected one hotel and wants full property details. Do not use for: broad city-level hotel discovery.
get_hotel_packages
ChatGPTFetch available room packages (room types, prices, bed configs) for a hotel. Requires the sId from search_hotels. Pass the SAME rooms array the search ran with for a multi-room stay — the packages are priced for that party, and each total already covers every room. After showing packages, ask the user which room they want to book. Use this when: a hotel is selected and room package choices are needed. Do not use for: before search_hotels returns sId and date context.
get_inbound_flights
ChatGPTAfter selecting an outbound flight on a round-trip search, fetch available return (inbound) flights. Call this with the search ID and the selected outbound flight ID. Extract flight filters from the user's message and pass them as arguments: - 'non-stop' / 'direct' → max_stops=0; '1 stop or less' → max_stops=1 - 'on Flynas' / 'with Saudia' → airlines=['Flynas'] (case-insensitive name match) - 'morning departure' (06:00–12:00), 'evening' (18:00–24:00), 'before 10am' → departure_time_min / departure_time_max in 24h HH:MM - 'arrive before noon', 'late arrivals' → arrival_time_min / arrival_time_max - 'under 1000 SAR' / 'between 500 and 1500' → price_min / price_max (total) - 'cheapest' → sort_by='price_asc' (default); 'fastest' → 'duration_asc'; 'earliest' → 'departure_asc'. Pagination: the result includes sId, offset, nextOffset, hasMore. When the user asks for more / next / others, call this tool again with s_id=<previous sId>, offset=<previous nextOffset>, and the SAME filter args — do NOT start a fresh search. Refining: when the user ADDS or CHANGES a filter (cheaper, only Flynas, morning departures, non-stop) the results are already loaded — call this tool with s_id=<previous sId>, offset=0, and the full filter set. Never re-send departure_code / arrival_code / dates for a filter change, and never start a fresh search. If totalMatched comes back 0, say so and offer to relax the filter instead of re-searching. Use this when: round-trip flow after outbound flight selection. Do not use for: one-way flow.
get_payment_link_for_non_seated_event
ChatGPTGenerate a checkout/payment link for a non-seated event via the email-based Hold AI endpoint. This does NOT confirm the booking — the user must complete payment first. REQUIRED arguments: user_email, event_id, event_slug, tickets. Optional: time_slot_id (for events with time slots), seven_rooms_details (for SevenRooms restaurant reservations), servme_details (for Servme restaurant reservations). EMAIL: Before calling this tool you MUST collect the user's real email address in chat ("What email should we use for the booking confirmation?"). Pass it as user_email. NEVER invent, guess, or use placeholders like 'user@example.com'. No sign-in is required — this tool uses email-based checkout, not OAuth. EXCEPTION — restaurant reservations: when you pass seven_rooms_details or servme_details, do NOT ask for an email. Those platforms require the user to be signed in, so the server fills user_email from their webook account automatically. Only ask if this tool answers error='missing_or_invalid_user_email'. TICKETS (PREFERRED): pass `tickets as a JSON array of objects: [{"id": "<ticket _id>", "qty": <int>}]. Each id MUST be the 24-char hex MongoDB _id from get_event_details' event_tickets[] — NEVER the ticket name or label. For multiple ticket types, include one object per type in the same array. TICKETS (fallback shape): if your runtime cannot express nested arrays, you may instead pass flat ticket_id (str) + qty (int) as top-level params for a single ticket type. The server will fold them into tickets — but the nested array is the canonical form and the only one that supports multi-type bookings. IDs: event_id MUST be the 24-char _id from get_event_details (e.g. '686b84ab9e7169446b0698c8'), NOT the slug. event_slug is the URL-style identifier. SEVEN_ROOMS_DETAILS: REQUIRED when check_restaurant_availability returned available_times with entries carrying shift_persistent_id + access_persistent_id (SevenRooms). Pass the 5 fields (party_size, date, time, shift_persistent_id, access_persistent_id) VERBATIM from the entry the user picked. OMIT for Servme restaurants (use servme_details), not_sevenrooms=true, and any non-restaurant booking. SERVME_DETAILS: REQUIRED when check_restaurant_availability returned available_times` with entries carrying a servme_details block (envelope has platform='servme'). Copy entry.servme_details VERBATIM: {date, time, guest_count, reservation_note}. OMIT for SevenRooms restaurants (use seven_rooms_details), not_sevenrooms=true, and any non-restaurant booking. Reservation IDs are validated server-side against live availability — copying the picked entry verbatim avoids a retry; a time that is no longer available returns error='slot_not_available' with fresh available_times to re-offer. ADDONS (optional): if get_event_details returned has_addons=true and the user selected extras from get_event_addons, pass addons=[{"id": "<addon _id>", "qty": <int>}]. IDs must be the 24-char _id values from the get_event_addons response — never names. Do NOT pass payment_method, lang, or is_wallet — they are ignored. Use this when: the event is non-seated (with or without time slots) and ticket details + user_email are already known. Do not use for: seated non-timeslot events or any case where event_id/ticket_id/user_email is unknown.
get_payment_link_for_non_seated_season
ChatGPTGenerate a checkout/payment link for a non-seated season via the email-based Hold AI non-seated endpoint. This does NOT confirm the booking — the user must complete payment first. Use this for every non-seated season, with or without time slots. If the season has time slots, run the slot flow first and pass the picked slot as time_slot_id. NEVER redirect the user to the website — seasons book here like events. REQUIRED arguments: user_email, season_id, season_slug, tickets. Plus time_slot_id when the season has time slots. EMAIL: Before calling this tool you MUST collect the user's real email address in chat ("What email should we use for the booking confirmation?"). Pass it as user_email. NEVER invent, guess, or use placeholders like 'user@example.com'. No sign-in is required. TICKETS: tickets is a JSON array of objects: [{"id": "<ticket _id>", "qty": <int>}]. Each id MUST be the 24-char hex MongoDB _id from the season_details response — NEVER the ticket name or label. IDs: season_id MUST be the 24-char _id from get_season_details, NOT the slug. season_slug is the URL-style identifier. Do NOT pass payment_method, ticket_qty, ticket_id, qty, or any other legacy parameters — they are ignored. Use this when: a season is non-seated, has no time slots, and user_email + tickets are already known. Do not use for: seated seasons or seasons with time slots.
get_payment_link_for_seated_non_timeslot_event
ChatGPTGenerate a checkout/payment link for a SEATED event via the email-based Hold AI endpoint. This does NOT confirm the booking — the user must complete payment first. Use this for every seated event, with or without time slots — seating is what selects this tool, not the presence of slots. If the event has time slots, run the normal slot flow first (check_time_slot_capacity → get_slot_tickets) and pass the slot the user picked as time_slot_id. NEVER send the user to the website to pick seats — seated events book here like any other event. REQUIRED arguments: user_email, event_id, event_slug, tickets. Plus time_slot_id when get_event_details returned has_time_slots=true. EMAIL: Before calling this tool you MUST collect the user's real email address in chat ("What email should we use for the booking confirmation?"). Pass it as user_email. NEVER invent, guess, or use placeholders like 'user@example.com'. No sign-in is required — this tool uses email-based checkout, not OAuth. TICKETS (PREFERRED): pass `tickets as a JSON array of objects: [{"id": "<ticket _id>", "qty": <int>}]. Each id MUST be the 24-char hex MongoDB _id from get_event_details' event_tickets[] — NEVER the ticket name or label. For multiple ticket types in a single booking (e.g. 2 adults + 1 child), include one object per type in the same array. TICKETS (fallback shape): if your runtime cannot express nested arrays, you may instead pass flat ticket_id (str) + qty (int) as top-level params for a single ticket type. The server will fold them into tickets` — but the nested array is the canonical form and the only one that supports multi-type bookings. IDs: event_id MUST be the 24-char _id from get_event_details (e.g. '686b84ab9e7169446b0698c8'), NOT the slug. event_slug is the URL-style identifier. ADDONS (optional): if get_event_details returned has_addons=true and the user selected extras from get_event_addons, pass addons=[{"id": "<addon _id>", "qty": <int>}]. IDs must be the 24-char _id values from the get_event_addons response — never names. Do NOT pass payment_method, lang, or is_wallet — they are ignored. Use this when: the event is seated and does not have time slots. Do not use for: events with time slots or non-seated paths.
get_payment_link_for_seated_season
ChatGPTGenerate a checkout/payment link for a seated season via the email-based Hold AI endpoint. This does NOT confirm the booking — the user must complete payment first. Use this for every seated season, with or without time slots. If the season has time slots, run the slot flow first and pass the picked slot as time_slot_id. NEVER redirect the user to the website — seasons book here like events. REQUIRED arguments: user_email, season_id, season_slug, tickets. Plus time_slot_id when the season has time slots. EMAIL: Before calling this tool you MUST collect the user's real email address in chat ("What email should we use for the booking confirmation?"). Pass it as user_email. NEVER invent, guess, or use placeholders like 'user@example.com'. No sign-in is required. TICKETS: tickets is a JSON array of objects: [{"id": "<ticket _id>", "qty": <int>}]. Each id MUST be the 24-char hex MongoDB _id from the season_details response — NEVER the ticket name or label. IDs: season_id MUST be the 24-char _id from get_season_details, NOT the slug. season_slug is the URL-style identifier. Do NOT pass payment_method, ticket_qty, ticket_id, qty, or any other legacy parameters — they are ignored. Use this when: a season is seated and has no time slots. Do not use for: non-seated seasons or seasons with time slots.
get_post_booking_recommendations
ChatGPTAfter a booking is completed (payment link shown or free booking confirmed), call this tool to get contextual recommendations for the user. Pass the booking_type (flight, event, hotel, restaurant, experience, season) and any relevant context (city, dates, event name). The assistant should then present the suggestions to the user. Use this when: a booking just completed (payment link shown or free booking confirmed) and you want contextual cross-sell suggestions to present. Reuse the booking's city and dates when the user picks a suggestion — do not re-ask.. Do not use for: mid-booking, or when the user declined further suggestions.
get_saved_passengers
ChatGPTRetrieve the user's saved traveler profiles so they can pick who is flying. Returns each traveler's ID, name and type only — never their identity documents. Use the selected IDs directly in prepare_flight_checkout. To add a new traveler, send the user the returned traveler_url; document details are entered on webook.com, never in chat. Use this when: immediately after select_flight returns — fetch saved travelers so the user can pick who is flying. Do not use for: before a flight is selected.
get_season_details
ChatGPTREQUIRED STEP before booking a season. Fetch full details for a Webook season by slug. Returns ticket categories, prices, and seated/time-slot flags. After calling this, ask the user which ticket type and quantity they want, then call the appropriate season payment link tool. Never ask how the user will pay — they choose that on the webook payment page. Use this when: the slug contains '--season--' (that marker IS the test for a season) and you must inspect ticket categories and booking flags. Do not use for: non-season entities — a slug WITHOUT the '--season--' marker is an event, even when its name says 'season'.
get_slot_tickets
ChatGPTReturn the ticket types that are configured AND have capacity for the user's chosen time slot. Call this after the user picks a time slot (via check_time_slot_capacity) and before presenting ticket options for a timed event. Use the returned tickets array verbatim when showing choices to the user — do not merge it with the full event catalog from get_event_details, which may include ticket types that are not bookable for this slot and would be rejected at checkout. Use this when: the user picked a time slot (via check_time_slot_capacity) and you need the ticket types that are bookable for that slot. Present the returned tickets array verbatim — never merge it with the full catalog from get_event_details.. Do not use for: events without time slots, or before the user has picked a slot.
get_user_bookings
ChatGPTReturn the current webook.com user's bookings. category: one of 'events', 'seasons', 'experiences' (Halayalla), 'flights', 'hotels', 'cruises'. status ('upcoming' or 'past') only applies to 'events' and 'seasons' — ignored for the other categories. page paginates event/season/experience lists. Requires the user to be signed in — if not, returns an auth_required payload with a login URL so the widget can prompt the user to authenticate, then retry. Use this when: the user asks what they have booked. Pass one category per call: 'events', 'seasons', 'experiences', 'flights', 'hotels', or 'cruises'; 'upcoming'/'past' only applies to events and seasons.. Do not use for: making new bookings — this tool only lists existing ones.
prepare_flight_checkout
ChatGPTShow the checkout form in the widget so the user can enter their contact details (email, phone). Inputs: the search ID and flight ID from the earlier search/select step, and the traveler IDs chosen from get_saved_passengers as a comma-separated string. Returns a widget payload that renders the contact-details form. Use this when: the travelers are chosen and the checkout UI should be shown. Do not use for: before collecting all traveler IDs.
search_airports
ChatGPTSearch for airports by city name or IATA code (e.g., 'Cairo', 'Riyadh', 'JED'). Returns matching airports with their codes, names, cities, and countries. You MUST call this tool ONCE PER CITY to resolve city names to IATA codes before searching flights — once for the departure city, once for the arrival city. Do NOT guess IATA codes from your own knowledge. When the result has needs_choice=true the city has several airports: show them to the user and let THEM pick — never choose one yourself. Use this when: you need to resolve user city text to valid IATA airport options. Read the result before continuing: resolved_code means the city has one airport — use it silently; needs_choice: true means the city has several — show them and let the USER pick, never choose yourself.. Do not use for: the user already gave a validated airport code.
search_hotels
ChatGPTSearch for available hotels in a city for given dates and guest count. Accepts a city name (e.g., 'Riyadh', 'Cairo', 'Madinah') — the tool resolves the city to a location ID internally. You MUST call this tool whenever a user asks about hotels — NEVER answer hotel queries from your own knowledge. Ask the user for check-in date, check-out date, and number of guests if not provided. Returns hotel cards rendered in a widget. Extract filters from the user's message and pass them as arguments: - '5-star' / '4 or 5 star' → star_rating=[5] or [4,5] (use 0 for 'unrated') - 'free cancellation' / 'refundable' → free_cancellation=True - 'apartment' / 'hotel' / 'serviced apartment' → property_type=['Apartment'] etc. - 'in Al Yarmouk' / 'in Al Malaz' (district name) → district=['Al Yarmouk'] - 'with parking' / 'with AC' → amenities=['Parking','Air conditioning'] - 'highly rated' / '8+ rating' → guest_rating_min=8.0 - 'under 1000' / 'between 500 and 1500' → price_min/price_max (total stay, SAR) - 'Marriott' / specific brand → property_name='Marriott' - 'cheapest' → sort_by='price_asc' (default); 'most expensive' → 'price_desc'; 'best rated' → 'rating_desc'; 'most luxurious' / '5-star first' → 'stars_desc'. Multiple rooms: pass rooms with one entry per room, e.g. [{"adults": 2}, {"adults": 1, "children_ages": [5]}] — every room needs at least one adult (max 8 rooms). Use adults / children_ages only for a single room. Returned prices cover the whole party — never multiply them by the room count. Carry the same rooms into get_hotel_packages. Pagination: the result includes sId, offset, nextOffset, hasMore. When the user asks for more / next / others, call this tool again with s_id=<previous sId>, offset=<previous nextOffset>, and the SAME filter args — do NOT start a fresh search. Use this when: the user asks for hotels in a city with travel dates. Do not use for: hotel booking checkout; this is discovery only.
search_one_way_flights
ChatGPTReturns LIVE one-way flight availability, schedules, and prices from the webook booking system between two airports on a given date. This IS the flight-search source — if you have departure_code, arrival_code, and outbound_date, you MUST call this tool rather than telling the user you cannot search flights. Requires IATA airport codes (e.g., RUH, CAI) — call search_airports first to resolve city names. Results render in a widget. You MUST always ask the user whether they want one-way or round-trip before calling this. PREREQUISITES — a fresh search is REFUSED unless you pass all of: departure_code, arrival_code, the date(s) and adults_count. There is NO default passenger count: ask the user how many passengers and their ages (adults 12+, children 2-11, infants under 2), then pass them. A bare total like '2 passengers' is not an age breakdown — ask. flight_class is OPTIONAL: pass it only when the user named a cabin and NEVER ask for it — an omitted cabin searches economy. These are not required on pagination/refine turns that pass s_id. Extract flight filters from the user's message and pass them as arguments: - 'non-stop' / 'direct' → max_stops=0; '1 stop or less' → max_stops=1 - 'on Flynas' / 'with Saudia' → airlines=['Flynas'] (case-insensitive name match) - 'morning departure' (06:00–12:00), 'evening' (18:00–24:00), 'before 10am' → departure_time_min / departure_time_max in 24h HH:MM - 'arrive before noon', 'late arrivals' → arrival_time_min / arrival_time_max - 'under 1000 SAR' / 'between 500 and 1500' → price_min / price_max (total) - 'cheapest' → sort_by='price_asc' (default); 'fastest' → 'duration_asc'; 'earliest' → 'departure_asc'. Pagination: the result includes sId, offset, nextOffset, hasMore. When the user asks for more / next / others, call this tool again with s_id=<previous sId>, offset=<previous nextOffset>, and the SAME filter args — do NOT start a fresh search. Refining: when the user ADDS or CHANGES a filter (cheaper, only Flynas, morning departures, non-stop) the results are already loaded — call this tool with s_id=<previous sId>, offset=0, and the full filter set. Never re-send departure_code / arrival_code / dates for a filter change, and never start a fresh search. If totalMatched comes back 0, say so and offer to relax the filter instead of re-searching. Use this when: the user confirmed one-way travel and you have ALL of: departure/arrival IATA codes, the outbound date and adults_count. Also used to paginate or re-filter an existing search via s_id.. Do not use for: round-trip requests, or any fresh search where the airports, date, or passenger counts by age are still unknown — ask the user first (never for the cabin class: it is optional).
search_restaurants_by_title
ChatGPTSearch Webook restaurants by a free-text title keyword. Renders the matching restaurants as inline cards. STOP after rendering — do NOT chain into get_event_details or any booking tool. The user browses the cards and will explicitly pick one on the next turn. Use this when: the user wants restaurant suggestions by keyword. Do not use for: restaurant booking; this connector supports search only.
search_round_trip_flights
ChatGPTReturns LIVE round-trip flight availability, schedules, and prices from the webook booking system between two airports with outbound and return dates. This IS the flight-search source — if you have departure_code, arrival_code, outbound_date, and return_date, you MUST call this tool rather than telling the user you cannot search flights. Requires IATA airport codes — call search_airports first to resolve city names. Returns outbound flight results. After the user selects an outbound flight, call get_inbound_flights to show return options. You MUST always ask the user whether they want one-way or round-trip before calling this. PREREQUISITES — a fresh search is REFUSED unless you pass all of: departure_code, arrival_code, the date(s) and adults_count. There is NO default passenger count: ask the user how many passengers and their ages (adults 12+, children 2-11, infants under 2), then pass them. A bare total like '2 passengers' is not an age breakdown — ask. flight_class is OPTIONAL: pass it only when the user named a cabin and NEVER ask for it — an omitted cabin searches economy. These are not required on pagination/refine turns that pass s_id. Extract flight filters from the user's message and pass them as arguments: - 'non-stop' / 'direct' → max_stops=0; '1 stop or less' → max_stops=1 - 'on Flynas' / 'with Saudia' → airlines=['Flynas'] (case-insensitive name match) - 'morning departure' (06:00–12:00), 'evening' (18:00–24:00), 'before 10am' → departure_time_min / departure_time_max in 24h HH:MM - 'arrive before noon', 'late arrivals' → arrival_time_min / arrival_time_max - 'under 1000 SAR' / 'between 500 and 1500' → price_min / price_max (total) - 'cheapest' → sort_by='price_asc' (default); 'fastest' → 'duration_asc'; 'earliest' → 'departure_asc'. Pagination: the result includes sId, offset, nextOffset, hasMore. When the user asks for more / next / others, call this tool again with s_id=<previous sId>, offset=<previous nextOffset>, and the SAME filter args — do NOT start a fresh search. Refining: when the user ADDS or CHANGES a filter (cheaper, only Flynas, morning departures, non-stop) the results are already loaded — call this tool with s_id=<previous sId>, offset=0, and the full filter set. Never re-send departure_code / arrival_code / dates for a filter change, and never start a fresh search. If totalMatched comes back 0, say so and offer to relax the filter instead of re-searching. Use this when: the user confirmed round-trip travel and you have ALL of: departure/arrival IATA codes, both dates and adults_count. Also used to paginate or re-filter an existing search via s_id.. Do not use for: one-way requests, or any fresh search where the airports, dates, or passenger counts by age are still unknown — ask the user first (never for the cabin class: it is optional).
search_webook
ChatGPTUnified Webook catalog search across events / experiences / shows / restaurants in one call. Extract STRUCTURED filters from the user message — keyword, city, country, date_from, date_to, price_min, price_max — and pass each as a SEPARATE argument. Never cram everything into keyword. Every call searches all four collections; there is no type/category narrowing parameter. Each returned item carries its own type discriminator that routes the user's selection to the right details tool. This is intentional — CMS miscategorisation (e.g. WWE stored as a show rather than an event) means narrowing by type would drop valid matches. HOTELS AND FLIGHTS ARE NOT IN THIS CATALOG. For hotel requests use search_hotels; for flights use search_one_way_flights / search_round_trip_flights. Calls that name those verticals are rejected WITHOUT searching and return searched=false plus a fallback_tool — follow the returned instruction instead of telling the user nothing was found. Worked examples: 'What can I do this weekend in Dammam?' → keyword='', city='Dammam', date_from/date_to = the two dates given for "this weekend" 'Italian restaurants in Jeddah' → keyword='Italian', city='Jeddah' 'concerts in Riyadh under 500 SAR' → the vertical goes in category or tags (see those parameters for the live slugs), city='Riyadh', price_max=500 — NOT keyword='concerts' 'Aquarabia' → keyword='Aquarabia' (no other filters) Parallel keyword rule: when the user names multiple distinct candidates ('Aquarabia or Asala'), issue ONE call per keyword in parallel — never combine them into one keyword. Max 3 parallel calls per user message. Pagination: the page size is fixed per collection. For 'show more' / 'next page', call again with the SAME filters plus skip=<page.next_skip> from the previous response. Always read next_skip off the response — never compute the offset yourself, because the page size is a server constant and has changed. Two independent filter axes — check BOTH before falling back to keyword: `category` / `category_exclude` — WHAT a thing is. The live slugs and the words that map onto them are listed on the `category` parameter itself; that list, refreshed from the CMS, is the only place a slug may come from. tags / tags_exclude (arrays) — WHO it is for or the occasion. Same: the live values are on the tags parameter. Several verticals live ONLY on this axis and have no category counterpart at all, so a word absent from category's list is not necessarily unfilterable — check tags before giving up on it. Both may be set in one call. zone narrows to a season hub and is only for when the user names the hub itself. Never invent a slug for any of these. A value outside the parameter's list is dropped silently, which makes a narrow query run UNFILTERED and answer a different question with full confidence — the observed failure mode is a request for one vertical coming back as a list of unrelated things. When no listed value fits, omit the field and let keyword carry the subject instead. Examples: 'family things to do, nothing ladies-only' → the audience words go in tags / tags_exclude 'things to do this weekend except restaurants' → date_from/date_to set, plus the dining slug in category_exclude Language: pass lang as one of 'en', 'ar', 'fr', 'es', 'pt' to localize the returned item URLs (e.g. Arabic conversation → lang='ar'). Defaults to 'auto', which infers the language from the query; unknown codes fall back to 'en'. city and country are independent — 'concerts in Morocco' is a country filter, and a city implies nothing about the country field. Both take the values listed on the parameters themselves; a value outside those lists is dropped silently. Returns a unified items list; each item carries a type discriminator. The results render as an interactive widget the user can browse on their own. STOP AFTER SEARCH — DO NOT CHAIN. After this tool returns, your ONLY action is a short text reply summarising what was found (e.g. 'I found 3 concerts in Riyadh this weekend'). Do NOT call get_event…
select_flight
ChatGPTSelect a flight (or outbound+inbound combination for round-trip) to lock it in for booking. For round-trip, flight_id is the composite ID (outbound/inbound). Inputs: search_id from the earlier flight search, flight_id of the chosen offer, and optional lang. Returns the locked selection needed for the passenger and checkout steps. Use this when: the user finalized a flight option and you need to lock it for booking. Do not use for: before fare/flight selection is complete.
select_hotel_package
ChatGPTSelect a room package to create a hotel reservation. Returns reservation details including hotelReservationId needed for checkout. After selection, ask the user for traveler details (name, email, phone) to complete booking. Use this when: the user chose a room package and reservation should be created. Do not use for: before package_id is confirmed.
start_webook_login
ChatGPTGenerate a one-tap Webook sign-in link bound to the current session. Call this when the user wants to sign in (or when a booking tool has just returned an authentication-required error and the user agrees to sign in). The link expires in 15 minutes. After the user opens it and completes sign-in, retry the booking tool and it will succeed without any further input. Use this when: the user wants to sign in to Webook, or a booking tool just returned an auth-required error and the user agrees to sign in. Do not use for: the user has already signed in (a previous booking call succeeded in this conversation).
