Travel fares · Fare alerts
Fare alert data: building reliable price-drop alerts
A fare alert is only as good as the price it sends. Stale, wrong-market or unbookable fares use up subscribers' trust quickly. Poll watched routes cheaply, then confirm every candidate drop with a live search from the right market before anything goes out.
Pay per GB · No subscription · Prices in EUR, excl. VAT
- €2.00
- per GB on ARC Fast, excl. VAT
- −44%
- at 1 TB (€1.12 / GB)
- 185+
- countries, city targeting
- Never
- expires — no subscription
Written for
- Fare-alert and price-tracker apps
- Flight-deal newsletters
- Travel media deal desks
- Product teams adding price watches
The short answer
- Use two tiers: broad, cheap polling to find candidate drops, and a narrow live confirmation from the subscriber's market before sending.
- Alert on the final price. In the EU, airlines must show the final price at all times, and unavoidable fees from the first price shown, so a fare without them is not the price your subscriber will see.
- Judge a drop against the route's own history (median, low percentile), not a fixed euro amount.
- Deduplicate watches across subscribers. Ten thousand people watching the same route and date are one poll, not ten thousand.
The problem
What goes wrong without the right IPs
Alerts for prices that no longer exist
Between detection and the subscriber's click, the cheapest seats can sell. Every minute of pipeline latency and every unconfirmed alert raises the 'price not found' rate, which is the first thing users complain about.
Alerts from the wrong market
A subscriber in Manchester who receives a fare observed from a German exit sees a different price, or currency, on click. Watches need a market, and confirmation has to run from it.
Polling everything all the time
Polling every watch at a fixed high frequency spends most of the budget on routes that have not moved. Adaptive cadence, frequent close to departure or after recent changes and slow otherwise, cuts cost without missing drops.
False drops from parsing and currency
A missing tax line, a currency switch or a one-passenger price shown for a two-passenger watch all look like drops. Validate the components and the party size before a candidate reaches confirmation.
Thresholds that ignore the route
Forty euros off is a bargain on a short hop and noise on a long-haul business fare. Drops measured against each route's own distribution produce fewer, better alerts.
What to collect
What you can collect
- Watch definition
- Route, date or date range, cabin, party size and market: the key you poll and confirm on.
- Polled price and time
- The cheap signal that a drop may have happened.
- Confirmed final price
- The live, bookable price from the subscriber's market. The only price you send.
- Route history statistics
- Median and low percentiles per route and lead time, to judge whether a drop matters.
- Drop size vs baseline
- Relative to the route's history, so thresholds travel across routes.
- Availability at confirmation
- Seats-left hints or bundle availability where shown.
- Deep link
- Where the subscriber lands, ideally the same market edition you confirmed on.
- Detection-to-send latency
- Your most important operational metric for alert quality.
How it runs
How a collection run works
- 01
Normalise and deduplicate watches
Collapse subscriber watches into unique keys (route, dates, cabin, party size and market). Polling cost scales with unique keys, not with subscribers.
- 02
Poll adaptively
Set cadence per key from days to departure and recent volatility; how often flight prices change gives sensible starting points. Use calendar or results views here: cheap and good enough to spot a candidate.
- 03
Confirm every candidate live, from the right market
Re-price the candidate on the full search flow with a fresh sticky session in the watch's market. Only a confirmed final price at or near the polled price becomes an alert.
Confirm before you send19 linesimport secretsimport httpxBASE_USER = "USERNAME_pool-arcfast_country-de"def live_client(market: str) -> httpx.Client: user = BASE_USER.replace("_country-de", f"_country-{market}") handle = secrets.token_hex(4) proxy = f"http://{user}_session-{handle}_sesstime-5:PASSWORD@proxy.arcproxies.io:8000" return httpx.Client(proxy=proxy, timeout=30)def confirmed_drop(watch, polled_price: float, baseline: float): if polled_price > baseline * (1 - watch.min_drop): return None # not a drop worth confirming with live_client(watch.market) as client: offer = reprice(client, watch) # your search + fare-detail flow if offer and offer.final_price <= polled_price * 1.02: return offer # send this, not the polled price return None - 04
Send fast, with the price's age
Queue confirmed alerts immediately and include when the price was confirmed. A clear 'confirmed 4 minutes ago' sets honest expectations if the fare moves before the subscriber clicks.
- 05
Feed outcomes back
Log clicks that landed on a higher price. That 'miss rate' per route and source tells you where to poll more often, confirm more strictly, or stop alerting altogether.
Setup
Recommended setup
Polling is high-volume and light; confirmation is low-volume and has to be right. Give each its own pool.
| Plan | Role | Session | Targeting | Price |
|---|---|---|---|---|
ARC Basic Rotating ISP | Watch-list polling High-frequency, low-weight requests to calendar and results views. The cheapest pool per GB keeps the polling bill flat as the watch list grows. Move a source to ARC Fast if it does not serve the ISP pool reliably. | Rotating | Country | €0.75 / GB €0.59 at 1 TB (−21%) |
ARC Fast Rotating residential | Live confirmation before sending Residential exits in the subscriber's market, held for one search-to-fare-detail flow. Only a small share of polls ever reach this stage. | Sticky, about 5 minutes per confirmation | Country, the watch's market | €2.00 / GB €1.12 at 1 TB (−44%) |
Prices are list prices in EUR, excl. VAT. Volume discounts apply automatically at checkout — full ladder on the pricing page.
Connect
One connection string per market
The country, city and sticky session are tokens in the username. Change the token, change the market; keep the session handle, keep the IP.
http://USERNAME_pool-arcfast_country-de_session-k3f9a1x2_sesstime-10:PASSWORD@proxy.arcproxies.io:8000Swap _country-de for any market you quote. The full grammar is on the residential proxies page.
Illustration
What five thousand watched routes costs
An illustration with round numbers — your pages, payloads and retry rate will differ. The arithmetic is the real price ladder.
Assumptions
- Unique watch keys
- 5,000
- Polls per key
- 4 a day, 200 KB each
- Candidates sent to confirmation
- 5% of polls
- Weight per confirmation flow
- 500 KB
- Bandwidth per month
- ≈ 135 GB
On ARC Basic
€91.80per month, excl. VAT
135 GB bought in one purchase at €0.68 / GB (−9% volume rung, applied automatically).
The same 135 GB on ARC Fast: €183.60 at €1.36 / GB. Route only the jobs that need it through the pricier pool.
Roughly 120 GB of polling and 15 GB of confirmation. In practice the polling share runs on ARC Basic and the confirmation share on ARC Fast; the comparison shows the whole volume on each.
Bandwidth never expires, so a bigger single purchase is only ever cheaper per GB. See the ladder.
In depth
Fare alerts, in depth
The architecture of a fare-alert pipeline
| Stage | Job | Pool | Weight |
|---|---|---|---|
| Watch store | Deduplicated keys: route, dates, cabin, party size, market | None | None |
| Poller | Adaptive-cadence checks on calendar and results views | ARC Basic, rotating | Light, around 100–200 KB |
| Candidate filter | Validate components and party size; compare with route history | None | None |
| Confirmer | Full live search from the watch's market | ARC Fast, sticky | Heavier, several hundred KB |
| Sender | Alert with confirmed final price, its age and a market-matched link | None | None |
Most of the cost sits in the poller and most of the quality in the confirmer. Teams that skip confirmation save a few percent of bandwidth and lose their subscribers' trust. The collection side is the same as for travel fare aggregation in general. How to build a flight price tracker walks through a minimal version end to end.
Setting thresholds that mean something
Keep a rolling distribution per route and lead-time band, for example the median and 10th percentile of confirmed prices for the same route 30–45 days out. Alert when a confirmed price falls below the low percentile, or by a set fraction below the median. Both travel across short-haul and long-haul without tuning per route.
Give the distribution enough history before you trust it, and exclude observations that failed validation. A broken parser that produced a week of artificially low prices will otherwise teach the threshold that broken prices are normal.
Alert copy that stays accurate
- Send the final price. EU rules require the final price, including unavoidable taxes and fees, to be shown at all times, and the Court of Justice has held that unavoidable items belong in the first price shown. An alert quoting less than that will not match the booking page.
- Name the market and currency. 'From London, in GBP' prevents most 'the price is wrong' replies.
- Show the age. 'Confirmed 6 minutes ago' is honest and reduces complaints when a fare sells out.
- Mention booking protections carefully. For flights covered by the US rule, carriers must allow a reservation to be held at the quoted fare without payment, or cancelled without penalty, for at least 24 hours if it is made one week or more before departure (14 CFR 259.5). Do not generalise it to flights it does not cover.
Freshness: how stale is too stale
Freshness requirements depend on how fast the underlying price moves. Close to departure, and on low-cost routes with few seats at each price step, a confirmation older than a few minutes is already a risk. Months out, an hour is usually fine.
Measure rather than guess. Log the share of alerts whose landing price was higher than the confirmed price, by route type and confirmation age. That curve tells you your real freshness budget. See also do airlines raise prices when you search?, the question subscribers will ask you when it goes wrong.
Keeping the polling bill flat
- Deduplicate. Unique watch keys, not subscribers, drive cost.
- Poll the lightest view. A calendar or JSON results endpoint is a fraction of a rendered page; see how to reduce proxy bandwidth.
- Adapt cadence. Slow down keys that have not moved in a week; speed up keys near departure or after a change.
- Be a light client. Airlines carry the cost of every shopping request; IATA's 2019 study found look-to-book ratios commonly above 10,000 to 1 for OTAs and metasearch. Fewer, better-aimed polls are cheaper for you and for them.
Works with anything that takes a proxy URL
- Python requests / httpx
- Node.js
Playwright- changedetection.io
- Docker
FAQ
Questions
Something not covered? Write to contact@arcproxies.io.
How do fare alert apps check prices?
Most poll a list of watched routes on a schedule, using light views such as fare calendars, and compare the result with each route's price history. The better ones then confirm any candidate drop with a live search from the subscriber's market before sending, so the alert quotes a price that can actually be booked.
How often should a fare alert check prices?
Adaptively. Check frequently close to departure and on volatile routes, and slowly for dates months away or routes that have not moved recently. A fixed high frequency for everything spends most of the budget on prices that did not change.
Why do fare alerts show prices that are gone when I click?
Because the cheapest seats sold between the check and the click, or because the alert was not confirmed live in the right market. Confirming every candidate on a full search from the subscriber's market, and sending immediately with the price's age, reduces the problem a great deal.
Should a fare alert include taxes and fees?
Yes, it should quote the final price. In the EU, airlines must show the final price including unavoidable taxes and fees at all times, so an alert quoting a lower base fare will not match the booking page and will look wrong to the subscriber.
How much does running fare alerts cost in bandwidth?
In our illustration, 5,000 unique watched routes polled four times a day, with 5% of polls confirmed live, use about 135 GB a month. Cost scales with unique routes and cadence, not with subscriber numbers. Bandwidth is billed per GB and never expires.
Do I need residential proxies for fare alerts?
For confirmation, yes: you want consumer-like exits in each subscriber's market. Polling can often run on the cheaper rotating ISP pool, because it uses light views and only has to spot candidates. Split the two and most of the volume lands on the cheaper pool.
Sources & review
Last reviewed by the ARC Proxies team. Prices are read from the live catalog at build time.
- [1]EUR-Lex (Official Journal of the European Union): Regulation (EC) No 1008/2008 on common rules for the operation of air services in the Community
- [2]Court of Justice of the European Union: Press release No 49/20: Judgment in Case C-28/19, Ryanair and Others v AGCM
- [3]Legal Information Institute, Cornell Law School: 14 CFR § 259.5 – Customer Service Plan
- [4]IATA: Addressing NDC scalability challenges in the leisure market (March 2019)
Travel fares
More on travel fares
Get started
Buy a gigabyte and try it on your own targets.
No subscription, no sales call. Code WELCOME15 takes 15% off your first purchase, and whatever you do not use is still there next quarter.