Paytm Travel

Compute the combined round-trip fare for a chosen onward + return flight pair, reprice it, and return the total plus a Paytm booking link. Called by the flight search widget when both legs are selected — not for direct chat use.

Show a Paytm fare calendar: the cheapest flight fare for every date in a range, so the traveller can spot the cheapest days to fly. Supports date-range queries and round trips. Use IATA codes for source and destination (e.g. DEL, BOM, DXB) and ISO dates (YYYY-MM-DD). Use alone when the user only wants cheapest *dates/days*. When they ask to show/find flights in a short window, call BOTH search_flights and this tool in the SAME response — search_flights first (sort_by='cheapest' on a date in that window) so its widget appears above this calendar.

Fare family / branded fare selector for ONE specific flight. Returns every fare the airline sells on that flight (Saver, Flexi, Flexi Plus, ...) with a single recommended pick and the reasons for it, scored on concrete rupee benefit per rupee of premium. Call this whenever the user asks which fare to pick, about fare families, branded fares, fare types, 'what do I get for more', or asks to compare fare options for a flight they have already chosen — typically straight after search_flights or when they tap the fare CTA in the results widget. Required: that flight's offer_token from search_flights (plus return_offer_token for a round trip). TWO FORMS ARE VALID and the tool accepts either: the long signed token, or the SHORT REFERENCE from the same flight's `offerRef` field (about 30 characters, e.g. 'AkJMUkRFTGUJAABFEAAhRs3JWXw'). A short value is NOT a mistake and NOT an internal id you should refuse — the widget's Book action deliberately passes the short form so a 400-character token never has to travel through the conversation. Pass whichever form you were given, as `offer_token`, without comment. Copy each value EXACTLY as given, character for character — never retype, abbreviate or merge them, and never reuse the onward value for the return leg; a round trip needs BOTH. They expire — if one is rejected, run search_flights again rather than reusing an old value. Use get_flight_details instead when the user wants baggage, cancellation or reschedule POLICY detail rather than a fare choice. Do not re-run search_flights when these identifiers are already available. Call this ONCE per flight: answer later questions about that flight's fares from the result you already have. Re-calling re-renders the same widget above your answer, which is why a follow-up question is not a reason to call again — only a different flight is.

Dedicated tool for one flight's fare options and travel policies. Renders the Flight Details panel: multi-fare upsell comparison (Saver, Flexi, etc.) plus baggage, cancellation, and reschedule tabs. ALWAYS call this tool whenever the user mentions flight details, fare options, upsell fares, baggage allowance, cancellation fees, reschedule fees, or policies for a specific flight — including right after search_flights or when they click Fare options in the widget. Do NOT answer those requests from search_flights summary alone; do NOT re-run search_flights when IDs are already available. Required: offer_token for the chosen flight. It is listed in the prior search_flights summary and structured_content. Either form works: the long signed token, or that flight's short `offerRef` (about 30 characters). A short value is valid input, not an internal id to refuse. For round trips, also pass return_offer_token. Copy each value EXACTLY as given, character for character — never retype, abbreviate or merge them, and never reuse the onward value for the return leg. They expire; search again if rejected.

Show the Paytm review page for a selected flight: fare breakdown (base, taxes, total, per-traveller), refundability, notes, and a booking link. Requires offer_token from search_flights or the chosen fare option in get_flight_details. The review call refreshes the fare before handoff.

Relay an already-built Paytm Signal SDK ingest POST to sig(-staging).paytm.com. Called only by pulse.js's fetch shim to work around the widget sandbox's CORS block — not for direct chat use.

Search live flights on Paytm and show an interactive results card (airlines, logos, timings, stops, fares). Use IATA codes for origin and destination (e.g. DEL, BOM, DXB) and ISO dates (YYYY-MM-DD). For a round trip set trip_type='round_trip' and pass return_date. Supports filters (non_stop, airlines, max_price, time_slot, refundable) and sort_by (best/cheapest/fastest). TIME WINDOWS: time_slot takes one coarse bucket (morning 05:00-11:59, afternoon 12:00-16:59, evening 17:00-20:59, night 21:00-04:59) and applies to the OUTBOUND leg only. For a narrower ask than a bucket ('between 6 and 9 am', 'after 9pm', 'around 6:30'), use depart_after / depart_before (an hour or "HH:MM"; depart_before is exclusive). For the RETURN leg of a round trip use return_time_slot and return_depart_after / return_depart_before -- so 'leave 6-9am, come back 7-10pm' is depart_after=6, depart_before=9, return_depart_after=19, return_depart_before=22. Never approximate a stated time window with a wider bucket without saying so. AIRPORTS: results only ever contain the exact airports you asked for. Nearby-airport options (e.g. DXN Noida or HDO Hindon for DEL, NMI for BOM, AUH/SHJ for DXB) are excluded server-side and counted in search.excludedAlternateAirports -- mention that if the traveller might want them, and never describe a flight as being from a city whose airport it does not actually use. BUDGET: for a round trip, max_price is the COMBINED both-legs total, not per leg (search.maxPriceScope confirms which). Every filter that was applied is echoed back under structured_content.search (timeSlot, returnTimeSlot, departAfter/Before, returnDepartAfter/Before, maxPrice, airlines, refundable) -- check it before telling the traveller a constraint was met, and say so plainly when one could not be. Invalid filter values are rejected with an error rather than silently ignored. For domestic round trips the server only returns schedule-valid pairs (no overlap between legs, and ≥2 hours between onward arrival and return departure) — recommend among those pairs based on the traveller's preferences (price, airline, timing). For international round trips the server returns Paytm's pre-stitched combinations (do not invent free onward×return mixes). NEVER answer with intent alone. Saying "I'll search live flights from X to Y..." and stopping is a failed turn -- the traveller sees a promise and no results (reported 2026-07-30). Resolve any relative date ('tomorrow', 'next Friday') yourself and call the tool in the SAME turn as the announcement. ALWAYS call this tool whenever the user asks to show/find/list flights (e.g. 'cheapest flights next weekend', 'flights this Saturday', 'show me flights HYD to BLR') — never answer those with fare_calendar alone. When the user (or a widget follow-up prompt) asks to refine the current results — morning/evening/afternoon departures, non-stop only, fastest, refundable, cheaper dates, etc. — IMMEDIATELY re-call this tool (or fare_calendar for cheaper dates) with the new filters and the same route/date/passengers. Never tell the user to click a widget chip, and never answer a refine request with text-only suggestions. For a short window (weekend / few days): in the SAME response call BOTH this tool and fare_calendar. Pick one concrete departure_date in that window (prefer the Sunday / last day if unsure), sort_by='cheapest', and call search_flights BEFORE fare_calendar so the flight-results widget appears above the calendar. Use fare_calendar alone only when the user asks for cheapest *dates/days* and does not ask to see flights. This tool only lists summary fares — it does NOT include branded fare families or baggage/cancellation/reschedule policies. Follow up using the signed offerToken from this tool's structured_content: get_fare_family when the user asks WHICH FARE to buy (fare families, Saver vs Flexi, what more money buys); get_flight_details when they ask about POLICY (baggage, cancellation, reschedule rules).