Scrape Wizz Air fares, routes and timetables at scale

Routes and dates are the core of the job. You give us the origin-destination pairs as IATA station codes and the booking window; we run search/timetable for the lowest fare per calendar date and asset/farechart for the fare curve and fare class around chosen dates. Flight-level detail - departure times, flight numbers, per-passenger pricing and bundle availability - comes from search/search, which sits behind a Kasada bot-management challenge (KPSDK). We scope that part separately and tell you before work starts which fields fall on which side of the line, rather than promising all of them. Collection runs as far ahead as Wizz Air has loaded the schedule for sale; past that horizon the calendar simply returns no data.

Daily suits most fare tracking and is the usual setting. Tighter refresh is workable on a defined shortlist of routes and dates rather than the whole network, because the 42-day window cap on search/timetable means a single route-year costs roughly nine chained requests - refresh rate and route coverage trade against each other. We size the schedule with you against that arithmetic and run at a request rate that keeps load on the origin low. The route map and station list change slowly and are normally refreshed weekly.

The booking engine picks currency from the departure station's country, not from the locale in the URL. Budapest to London Luton quotes HUF, Luton to Budapest quotes GBP, Warsaw to Rome Ciampino quotes PLN. The route map lists eighteen currencies across the network: EUR, HUF, PLN, RON, GBP, CHF, CZK, DKK, NOK, SEK, RSD, MKD, BAM, ALL, GEL, MDL, AED and USD. Each price object also has exchangedAmount and exchangedCurrencyCode, which stay null unless a conversion is requested. We keep the native price.amount and price.currencyCode untouched and add a converted column at a stated reference rate and date, so a route quoted in HUF and one quoted in GBP sit in the same comparable table.

That is the failure in-house scripts hit most often. The version segment in https://be.wizzair.com/{version}/Api increments with each release, and a client pinned to an old number stops resolving - the reason older community scrapers frozen at 8.7.x, 9.0.1, 10.1.0 or 10.3.0 no longer work. We read the current version from the front end's runtime configuration on every run instead of hardcoding it, and watch for changes behind it: a renamed field, a tightened validation rule, a station that disappears from the map. When something moves, the repair is ours and the feed keeps arriving. Maintenance is part of the service, not a new project.

No. We collect publicly available data and do not authenticate. WIZZ Discount Club (WDC) and WIZZ MultiPass prices are shown only to signed-in members, so they are out of scope and what you receive is the public fare. Booking retrieval is out too: Find Booking needs the six-character alphanumeric confirmation code, the PNR, plus the lead passenger surname, or a My WIZZ Account sign-in. The robots.txt file disallows the booking, check-in, itinerary and profile paths under every locale it lists, 29 of them on a recent read, and we honour that. We also do not sell challenge evasion or CAPTCHA solving: the www host sits behind an AWS WAF Human Verification challenge and the flight search call behind Kasada, and where a control blocks automated access we treat it as a project boundary. On legality, gathering public fare information is broadly accepted practice, but the site terms and your intended use are a question for your own counsel, and we scope the work around their answer.