Use case
Fare alerts that fire on a verdict
Alert when Google itself says the fare is low, not when it crosses a threshold you guessed.
A fare alert is only useful if it knows what a good price is, and most alert systems answer that by collecting months of their own price history before the first useful notification. That is a database, a backfill job, and a statistical model, all to reconstruct something Google Flights already computes per route and date. And once the alert runs unattended, a failed scrape that returns an empty list quietly becomes a false “no flights” message to a real user.
How FlightPowers helps
Three capabilities carry the whole job
The verdict field is the trigger
price_range_in_relation_to_other_periods returns Google's own low | typical | high call on every fare, next to the price_insights_low/high band it was judged against. Your alert logic is one comparison, not one model.
X-Search-Status keeps alerts honest
An unattended poller can't eyeball failures. The header separates a real “empty” from a “degraded” search that should be retried, so the alert never reports a scrape failure as a fare event.
buy_link makes the alert actionable
Every result carries a deep link into Google Flights for that exact itinerary. The notification can end with “book it” instead of “go search for it again.”
Key workflows
What an alert pipeline looks like
- Poll on a schedule. A cron job, an n8n workflow, or an agent checks each watched route once or twice a day: one request per route per check.
- Branch on the verdict. Fire when
price_range_in_relation_to_other_periodsflips to"low"; stay silent on typical and high. - Guard with the header. Skip and retry any response whose
X-Search-Statusis degraded: never turn a failed search into a notification. - Send the band as context. “$412: the usual range is $480–$620” is a message a user can act on without opening a search page.
- Attach the buy_link. One tap from the notification to the exact itinerary on Google Flights.
Questions, answered plainly
- How do I know a fare is “low” without collecting my own price history?
- Every result carries price_insights_low and price_insights_high (Google’s historical price band for that route and date window), plus price_range_in_relation_to_other_periods, Google’s own low | typical | high verdict. Your alert branches on the verdict; Google’s band is the history you didn’t have to collect.
- Will my alert misfire when a search fails?
- Not if you read the X-Search-Status header. “empty” means Google genuinely has no itineraries, a real answer. “degraded” means the search did not complete and the empty array says nothing about availability: retry instead of alerting. Opt-in strict mode turns a degraded search into an HTTP 503 if you prefer an error.
- How many routes can one plan watch?
- One check is one request. A Pro plan ($10/month, 2,500 requests) checks 5 routes every morning with most of the quota left over; the 150 requests/minute rate limit means a batch of checks runs as one burst, not a slow loop. Larger watchlists fit Ultra or Mega.
Ship the alert, skip the database
Google’s price band rides on every result, on every plan, including the free tier you can verify a key with.
Free tier: 10 requests/month. No card to try.