OpenClaw Use Case: Real-Time Flight Fare Tracking

If you've asked an AI agent to find you a flight, the results have probably been mixed. Sometimes you get a price from an article written six months ago, or the typical fare for that particular route. A lot of that comes from how the agent fetches its data: general web search returns pages built for humans to read, not data structured for an agent to work with. agent-data solves this by exposing live fare search, flight status, and airport conditions as machine-readable endpoints — see the Flight Information endpoint for the full schema.

This post walks through the pattern end-to-end: writing a natural-language prompt, what OpenClaw returns to you, what it's actually doing under the hood, and how to put the whole thing on a recurring schedule so the agent only pings when something meaningful changes. By the end, you'll have a fare watcher for one route and a repeatable pattern you can point at other live APIs in the library.

Setup: install agent-data (if you haven't already)

If you've already got agent-data connected to OpenClaw, skip ahead. If not, the shortest path is one command:

npx -y agent-data init

That installs the CLI and walks you through API-key setup so you can access the flight-data library. You can also have OpenClaw walk you through the setup flow directly.

What you see: prompts and what OpenClaw returns

From your side, this is just a natural-language prompt:

A few useful variations include:

Threshold watcher:

Business traveler:

Flexible dates:

OpenClaw figures out which API in the agent-data library handles flight searches, calls it with the right parameters, and comes back with a ranked list. In this case that's the Flight Information endpoint. On the JFK → SFO query above, and at the time of writing this article, it returned JetBlue B6 515 as the cheapest nonstop at $299.

OpenClaw can summarize tradeoffs like price vs. duration in plain language without you having to look at the raw data. It can also apply your preferences before you ever see the shortlist — removing red-eyes, excluding airlines you don't want, optimizing for arrival time instead of headline price.

Once the search is recurring, OpenClaw can compare the current result to the previous one. Instead of sending you the same table three times a day, it can say something like:

What the agent sees: discovery and structured fare data

This section is more of an under-the-hood look. You don't need to read it to use the workflow, but it's useful for debugging when something doesn't behave the way you expect.

OpenClaw first searches the library for the right API:

$ agent-data search "live flight fares and status"

That returned the Flight Information API. To keep things readable, I'll abbreviate its UUID below as [Flight Information API UUID].

It then reads the docs to see what routes are available:

$ agent-data docs [Flight Information API UUID]

Relevant routes include search-flights, get-flight-search, get-flight-status, and track-flight.

With the appropriate route identified, the agent kicks off the fare search:

$ agent-data call [Flight Information API UUID] search-flights \
  --date 2026-05-22 \
  --origin_iata JFK \
  --destination_iata SFO \
  --max_stops 0 \
  --sort price \
  --limit 5 \
  --compact true

This route is asynchronous, so the first response is a job envelope rather than the final fare list:

{
  "data": {
    "job_id": "flight_search_job_e3a77444e9fc47e08ba07a02a322ac2e",
    "status": "completed",
    "poll_url": "/api/v1/flight-searches/flight_search_job_e3a77444e9fc47e08ba07a02a322ac2e",
    "operation_id": "operations/17100229f73e417aaabf88148c9dc16d"
  },
  "meta": {
    "resource": "flight_search_job",
    "sources_used": ["skiplagged"]
  }
}

OpenClaw then fetches the result by job_id:

$ agent-data call [Flight Information API UUID] get-flight-search \
  --job_id flight_search_job_e3a77444e9fc47e08ba07a02a322ac2e

A trimmed sample of the actual response:

{
  "data": {
    "status": "completed",
    "result": {
      "origin_iata": "JFK",
      "destination_iata": "SFO",
      "date": "2026-05-22",
      "offers": [
        {
          "price_usd": 299,
          "cabin_class": "economy",
          "outbound": {
            "airline": { "iata": "B6", "name": "JetBlue Airways" },
            "stops": 0,
            "duration_minutes": 402,
            "segments": [
              {
                "flight_number": "B6 515",
                "origin_iata": "JFK",
                "destination_iata": "SFO"
              }
            ]
          }
        },
        {
          "price_usd": 379,
          "cabin_class": "economy",
          "outbound": {
            "airline": { "iata": "B6", "name": "JetBlue Airways" },
            "stops": 0,
            "duration_minutes": 383,
            "segments": [
              {
                "flight_number": "B6 115",
                "origin_iata": "JFK",
                "destination_iata": "SFO"
              }
            ]
          }
        },
        {
          "price_usd": 429,
          "cabin_class": "economy",
          "outbound": {
            "airline": { "iata": "DL", "name": "Delta Air Lines" },
            "stops": 0,
            "duration_minutes": 397,
            "segments": [
              {
                "flight_number": "DL 365",
                "origin_iata": "JFK",
                "destination_iata": "SFO"
              }
            ]
          }
        }
      ]
    }
  }
}

The response already has prices, stops, airline names, durations, segment flight numbers, and freshness metadata, so OpenClaw can filter, compare, and summarize without parsing anything itself. The first call usually involves discovery (search → docs → call), but later calls can reuse the path discovery established, so a scheduled job can skip straight to search-flights.

Run it on a schedule with OpenClaw cron

Scheduling is how this stops being a one-off query and starts running on its own.

Once you know the right listing and route, you can schedule a recurring isolated job to re-run the check and announce only meaningful changes:

openclaw cron add \
  --name "Watch JFK-SFO fares" \
  --cron "0 7,13,19 * * *" \
  --tz "UTC" \
  --session isolated \
  --message 'Check nonstop JFK to SFO fares for 2026-05-22. Compare with the previous result for this route/date if available, and alert me only if the cheapest fare dropped below $325 or changed by at least $40.' \
  --announce

Two practical notes. First, use an isolated cron job for this kind of recurring workflow. Second, wrap the --message in single quotes if you include dollar thresholds like $325 or $40, otherwise your shell may expand them and silently corrupt the instruction.

A few natural follow-ons include:

Why agent-data instead of web search or browser automation?

A reasonable question — couldn't OpenClaw just use web search, or drive a browser to find this information?

Web search is the most obvious alternative and the weakest fit. Route-pricing queries tend to return articles that are useful for understanding a route's typical fares but less so for precise, real-time data.

Browser automation can fill the gap, but it's generally slow, expensive, and flaky. The agent pays for a screenshot at every step, which adds up fast when the job is running on a schedule. And it can only act on what the page is currently rendering, so anything below the fold — like the rest of a paginated fare list — requires another turn.

agent-data addresses both problems for flight data, and any data source the library includes.

Other travel use cases for OpenClaw

Track flight status from chat

The same listing exposes get-flight-status, so OpenClaw can watch a specific flight and summarize whether it's on schedule, delayed, or rerouted.

Monitor airport delays before departure

You can also query airport-level conditions and boards instead of individual fares — useful when the thing you actually care about is operational risk rather than ticket price.

Compare airport weather before booking

Because the listing also covers airport conditions, you can combine fare shopping with operational context. The agent can flag when a cheap fare lines up with a bad weather window at the destination, which is helpful when you're booking far enough in advance to have alternatives.

Build a weekend getaway watcher

Once the fare-monitoring pattern works for one route, you can generalize it across destinations and budgets. The result is closer to a trip scout than a one-off query.

Give your OpenClaw agent live flight data

Install agent-data, connect it to OpenClaw, and turn one flight search into a recurring fare watcher.

Full docs: docs.agent-data.dev. OpenClaw docs: docs.openclaw.ai.