Paytm Travel

Legacy helper — prefer the widget's get_bus_ai_summaries path. Do not call this after search_buses in normal chat (it has no UI template and must not spawn a second results card). If used, pass summaries as [{tripRef, summary}] plus echoed search/buses/currency/followups/disclaimer; each summary is one 15–30 word differentiating line. Omit entries with nothing differentiating.

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.

Internal: called by the bus-search widget after search results render. Prefers search_context from search_buses meta (card raw trips + universe index) so it skips a second search; falls back to re-fetching the route when that handoff is missing. Builds differentiating one-liners from the search payload only (no bus-details calls) via Azure OpenAI inside this server. Empty summary per card is valid when nothing differentiates. Both ChatGPT and Claude widgets call this — do not use apply_bus_summaries to render a second results card.

Show the Bus Details sheet for one trip from search_buses: amenities (iconified), pickup and dropping points with times, cancellation-policy slabs, rating, and a Book on Paytm Checkin CTA. ALWAYS call this when the traveller asks about amenities, boarding/dropping points, cancellation policy, or details for a specific bus — including when they tap a bus card in the widget. Do NOT re-run search_buses when tripRef is already available. Required: trip_ref — the opaque tripRef from the prior search_buses card (copy it exactly). Optional: summary (the card's AI summary line) and booking_url (the card's Paytm hand-off link). No seat map or payment in chat — booking continues on Paytm Checkin.

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. When they tap Continue (or ask to review / book the fare they are looking at), the next tool is get_flight_review — that follow-up arrives as a new user turn naming the offer_token and the selected fare's price; call get_flight_review immediately with those exact arguments so the flight details / review page renders as its own card. 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 flight details / review page for a selected fare: itinerary summary, fare breakdown (base, taxes, total), refundability, and a Book on Paytm Checkin link. The review call refreshes the fare before handoff. ALWAYS call this tool when the user (or a widget follow-up) asks to continue, review, see flight details for a chosen fare, or book after picking a fare in get_fare_family — including the fare-family Continue CTA, which posts a new user turn naming this tool. Do NOT skip this page and send them straight to Paytm. Required: offer_token from search_flights / get_fare_family (the long signed token or that flight's short `offerRef` — a short value is valid, not an internal id to refuse). Copy it EXACTLY. For a round trip also pass return_offer_token. Optional: price and fare_name of the branded fare the traveller picked (and return_price / return_fare_name on a round trip). Pass those through verbatim when the widget or the user named them, so review reprices THAT product (Saver vs Flexi have different Paytm ids). If the user asks to review / continue / book WITHOUT naming a fare or price, still call this tool in the SAME turn with the offer_token you already have — omit price. The tool fetches the recommended (best-value) fare from the fare family and reviews that. Do not invent a total, and do not re-run search_flights or get_fare_family just to guess a fare.

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 Paytm bus routes and show an interactive results card (operator, bus type, timings, rating, seats left, price). One-way, domestic, search only -- no seat selection or booking happens in chat. REQUIRED ARGS (same posture as search_flights): source, destination, and date are ALL mandatory. source/destination are free-text city names (e.g. 'Bengaluru', 'Hyderabad'); date is YYYY-MM-DD. If the traveller did not give a travel date (or source/destination), ASK for the missing field(s) and do NOT call this tool yet — never invent today/tomorrow/a weekend, never default a date, never search on a guessed date. Only resolve a relative date ('tomorrow', 'next Friday') when the traveller actually said one. CITY DISAMBIGUATION IS MANDATORY: many Indian city names are ambiguous (e.g. 'Aurangabad' matches cities in Maharashtra, Bihar, Uttar Pradesh and West Bengal). If the response has needsDisambiguation=true, do NOT guess which one the traveller means -- show them sourceCityOptions / destinationCityOptions and ask, then re-call this tool with the chosen source_city_id / destination_city_id (the free-text source/destination must still be passed too). Filters: bus_type — pass 'AC' or 'Non-AC' when the traveller only named climate ('ac buses', 'non ac'); pass a full type ('AC Sleeper', 'AC Semi-Sleeper', 'AC Seater', 'Non-AC Sleeper', 'Non-AC Semi-Sleeper', 'Non-AC Seater') only when they named a berth. Do not invent a berth. time_slot (morning 04:00-09:59, afternoon 10:00-15:59, evening 16:00-21:59, night 22:00-03:59), depart_after/depart_before (hour or "HH:MM", for a narrower window than a bucket), operators (list of operator names), max_price, min_rating, paytm_assured, boarding_point (matches by area name across all boarding points). Sort: recommended (default) | cheapest | fastest | earliest | rating. Invalid filter values are rejected with an error rather than silently ignored. Ratings below 15 reviews are not shown -- treat a missing rating as 'not enough reviews yet', not as a bad bus. Named filters are sent to the Paytm wrapper (e.g. AC → is_ac) and the matching buses are shown. If those filters match nothing, tell the traveller — do NOT re-call this tool without the filters unless they ask to drop them, and never open a second unfiltered results card for the same query. NEVER answer with intent alone when source, destination, AND date are all present -- resolve any relative date the traveller stated ('tomorrow', 'next Friday') yourself and call this tool in the SAME turn as the announcement. When the user refines the search (only AC, cheaper, leaving after 9pm, better rated, etc.), IMMEDIATELY re-call this tool with the new filters and the same route/date -- never tell them to click a widget chip. This tool lists a per-trip Paytm Checkin seat-layout URL as the dweb booking link (bookingUrl) and a matching seat deeplink for mweb/app (bookingDeeplink) -- there is no in-chat seat selection or payment; the traveller completes booking on Paytm Checkin. When the traveller asks about amenities, boarding/dropping points, or cancellation for a specific bus (or taps a card), call get_bus_details with that card's tripRef — do not re-search. AI CARD SUMMARIES: The bus-search widget loads one-line AI summaries itself (skeleton footers, then text or remove). Do NOT call apply_bus_summaries after search — that would open a second results widget. Do not invent amenities or ratings in chat text.