Hacker News new | past | comments | ask | show | jobs | submit login

> Does each airline have their own way of exporting this data? Is there a single entity that aggregates from all of them?

I work with a lot of smaller airlines, and from my experience I can tell you no. Many of them can't even tell you their actual route list or flight schedule or pricing logic. They typically buy a booking engine solution from just a few major players (Sabre, Amadeus, TravelPort) who do have centralized data, but access to them is slow, expensive (at scale) and restrictive.

I've been told by one of the GDS's that our use case doesn't apply for direct GDS access, and we have to go through the airlines' access method. I don't know if these booking engine solutions include access to an API or not, however most airlines have said either they don't have an available API, or don't know how to share access to one.

Some of the larger airlines do seem to have their stuff together. But we're just starting to work with them, and because of all the bureaucracy involved it will likely be months before anything happens.

The screen scraping method djhworld mentions is a worthwhile approach if you'd personally like to track a few routes. I've done the same to watch prices to NYC (I visit friends often) on a few of the low-cost airlines. It's nice because you can tailor the logic to your preferences. Such as don't bother searching flights that don't include a weekend in the trip; or set my alert threshold 25% higher when the trip involves a holiday or long weekend.

We built Hitlist (hitlistapp.com) to make this accessible to laypeople - I used to do the same thing you mention, scraping specific routes I knew I was going to fly. It's far from perfect but makes it easier to browse lots of date/destination options at a time.

What is your specific use case? I used to work managing API's for one of the GDS companies

For screen scraping, there are a number of companies that do this already for multiple carriers. I'd suggest making use of one of these rather than reinventing the wheel. Example: http://xmldocs.travelfusion.com

My project definitely isn't applicable because it requires caching prices, I don't remember why we were declined access for our other teams/products though. I would have to ask them, as it's been a while.

About screen scraping, I guess it depends on how quick you are at writing scraping scripts (and if you find it fun). I could probably write one faster than I could register for that API. You're also adding a layer between you and the prices. You don't know how long Travelfusion has cached these prices for, while it's simple to write a script that opens the real booking engine to get correct prices. I typically only run mine when I'm ready to purchase a ticket, but don't know which dates, rather than running it constantly to find deals.

And if I were doing anything more than a few routes on a few carriers, I definitely would use a real API instead of reinventing the wheel. In this case I just think it's kinda fun.

Your information is spot on. I have been working with Sabre daily for a few years now, and I don't want to think about the time I have wasted waiting for a Sabre response... it does go down once a week, which I guess is a perk

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact