Chase (secure.chase.com) for AI Agents

On the banking side, your agent opens the accounts overview with view_accounts_overview, drills into a specific card with view_account_detail (by account_id), and reads recent activity with view_transactions. For a machine-readable export, download_transactions walks the See all transactions flow, captures the CSV server-side, and returns a download link in data.download.url. Statements, tax documents, scheduled payments, and profile info each have their own action, and rewards come in two flavors: view_rewards_balance reads the points shown in the Chase Travel header, while view_rewards opens the separate Ultimate Rewards site.

On the travel side, open_travel_tab lands on a product tab (flights, hotels, cars, activities, cruises, tours). For flights, search_flights fills origin, destination, and round-trip dates; filter_results exposes the Recommended / Cheapest / Fastest sort tabs; and view_results reads the itinerary grid where every fare family is priced in both cash and points. view_points_boost reads the Chase-specific points-multiplier discounts, the highest-signal datum for points optimization. From there select_outbound_flight, select_return_flight, and view_trip_cart assemble and review a full round trip.

These come straight from the mapped action behavior, not guesswork.

**Flight selection is cheapest-only.** select_outbound_flight and select_return_flight always take the cheapest fare of the cheapest listed flight. There is no way to pick a specific flight, airline, or fare class, and your agent should never tell the user a particular carrier was chosen. The recipes handle the messy parts for you: they answer the 'Upgrade for more flexibility' modal some carriers pop over the results, and they confirm the fare-upsell interstitial after Add to trip. Without that confirm the leg never lands and the cart stays empty.

**Search inputs are picky.** search_flights matches the autocomplete on typed text, so pass a city or airport name (San Francisco), not a bare code. Dates must fall within the roughly two months the calendar shows by default; further-out dates are not yet reachable.

**rerun_recent_search is a replay, not a search.** It re-opens whatever route and dates were last searched, which may differ from the current request. Your agent must state the saved route and dates before presenting those results, and must never use it as a silent fallback when search_flights fails.

**CSV vs PDF.** For any export-my-activity request, use download_transactions (CSV). view_statements returns PDF account statements, not transaction data.

This is a signed-in portal: every action described on this page except login itself requires auth. The login action takes username, password, and otp, and starts from the secure dashboard login URL. On a fresh browser Chase presents a per-login identity-verification challenge; the recipe auto-selects text (SMS) delivery, advances to the code screen, and pauses for the user's texted code. So the flow is: your agent dispatches login, the session waits, the user reads the code off their phone, and the agent supplies it as otp. From that point the whole banking and travel surface is open for the session.

Each stage of a flow lands on a mapped screen, and your agent reads structured output from it rather than scraping. Flight searches resolve on flight_results, where each itinerary row carries airline, times, duration, stops, and every fare family in both cash and points, including Points Boost strikethroughs. The assembled round trip lives on trip_cart, which lists both legs and the total in cash and points; note the round-trip total there is best-effort today, since Chase renders it inside a web-component shadow DOM, so treat cart navigation as the verified part. Account flows resolve on account_detail and transactions, the CSV export runs through download_activity, statements and tax documents surface on documents, and the travel portal entry point is travel_landing.