Hacker News new | past | comments | ask | show | jobs | submit login
Google is shutting down the QPX Express API for airfare data
324 points by imartin2k on Oct 31, 2017 | hide | past | favorite | 190 comments
Google has been offering an API for airfare data at https://developers.google.com/qpx-express.

I just received this email:

"Dear QPX Express API Customer, After careful consideration, we've decided to shut down the QPX Express API as of April 10, 2018.

How this affects you

After April 10th, you will not be able to access the API and will no longer be charged for this service. Until then, you will be charged a reduced rate of $0.02 per query for any queries beyond the 50 free daily quota.

Next steps

You don't need to take any action. However, if you are actively using this product you may want to find an alternate solution before April 10, 2018. If you have any questions about these changes, please don't hesitate to contact us at any time. Sincerely,

The QPX Express API team"

More info on the shutdown: https://developers.google.com/qpx-express/faq#EndOfServiceFAQs




From [1]: "On April 8, 2011, the US Department of Justice approved the buyout (of ITA by Google). As part of the agreement, Google must license ITA software to other websites for five years."

Now that five years are up, Google would want to deny competitors access to that data. Seems like a good startup opportunity.

[1] https://en.wikipedia.org/wiki/ITA_Software


Reminds me a few google employers posts on HN responding to the usual 'google closes products often': we dont, and we never closed a business products, only unimportant consumer ones.

Yeah, sure.

Google is heading Microsoft 199x way - fastly becoming public enemy no 1.


Cute language. So just to be clear, you're putting Google ahead of North Korea, ISIS, et al on the list of threats to humanity?


Good heavens, this is exactly the kind of thing the guidelines refer to here:

> Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.

https://news.ycombinator.com/newsguidelines.html


I think it's odd to even include ISIS on any list of "threats to humanity." How many orders of magnitude could more damage could Google do by accident compared to ISIS?


In this context, I intended "threat to humanity" to mean "a clear and present danger to the safety and security of human beings."

ISIS very intentionally kills people opposed to its goals. Google, by comparison, does not.

Whether Google is the origin story of a 1984-like dystopia is another question entirely.


Not even mentioning ISIS was created by the CIA. The US is the largest state sponsor of terrorism, but private internet megacorps are the biggest threat to freedom of speech. They're both pretty bad threats, just in very different ways.


How is ISIS top 2 on your list of threats to humanity? They are at best a regional threat. Google can do considerably more damage on a global scale.


The two examples I gave were not the top two, nor in any particular order.

However, they do make a practice of killing people, which Google does not.

Also, the elimination of a minor API is hardly a globally-damaging action.


[flagged]


> IS has directly been responsible for hundreds of thousands of deaths and many more injuries

So has the USA, and likely all current first-world countries. Should the USA not be #1 on the threats to humanity? Actually, come to think of it, drinking has been directly responsible for hundreds of thousands of deaths and many more injuries. Maybe that should be #2?

Your list of threats is just the current round of scare mongering topics. Noticeably lacking are actual threats, like climate change and the rise of nationalism. And yes, a company that controls as much information (and access to that information) can be very very dangerous.


Literally hundreds/thousands of people are killed by our own citizens every day, I'm not concerned with an additional 8. Google has the ability to negatively affect hundreds of millions of lives on a global scale over a significantly long term. ISIS is not even in the same ballpark.


Clearly the OP meant in the context of anticompetitive action the tech industry, not including foreign (at war) countries that have concentration camps. This kind of snark really takes away from the discussion.


Why is North Korea a threat to humanity?


A possibility exists that North Korea might be able to bait someone into a nuclear war.


Come on, I have no sympathy for NK's regime, but that's victim blaming.

The threat is "baiting someone into nuclear war" and not "having tens of thousands of nuclear warheads and being ready to use them to kill millions of people"? Give me an effing break mate :)


I think this is highly unlikely. There's simply no point. NK needs nuclear weapons to stave off possible US invasion. They are not crazy people. Crazy people can't create nuclear weapons just to randomly kill people for no reason.


> Seems like a good startup opportunity.

Last time this was brought up (2011 HN article IIRC), it was discussed how terribly organised the travel industry is and just how much Smart Work ITA did and how invaluable it was.


TLDR: Not a startup opportunity.

- Huge collection of proprietary data which is constantly updated, only intended to be polled in a certain way and has all kinds of poorly structured exceptions and routing problems.

- The booking engines provide good access to their pricing data free of charge under license to affiliates that book flights through their engine

- Low value of an API for prices alone and slim chance of acquisition by Google or the big online travel agents

ITA built exceptional technology rather than an exceptional business.

This API that Google killed presumably because it wasn't making enough revenue to be worth maintaining was the part of ITA's public facing service they originally claimed to be "very excited" about at the acquisition stage


Relevant threads:

https://news.ycombinator.com/item?id=2424592

https://news.ycombinator.com/item?id=2992660

(Algolia's HN search is invaluable: https://hn.algolia.com/ )


seems a little bit more than 5 years...


I wonder if this was five years from the deal closing? Usually the deal doesn't close until after regulators have agreed to not to file a lawsuit (which is what happened on the April 8th 2011 date).


That still implies it took them 2 years to close the deal (2018-5=2013) which seems a bit much.


> Now that five years are up

2018 - 2011 = 7?


7 > 5, so the 5 years are up.


Well, the question is why did Google wait the 2 non-required years before shutting it down? Seems like something they wouldn’t just forget about.


They've been up for 2 years, so how is it "Now that five years are up, Google would want to deny competitors access to that data"? If that was their reasoning they would've done it 2 years ago. It's 2 years of extra advantage they didn't need to give their competitors, right?


Now that the five years are up and Google Flights just started facilitating actual airfare purchases (a recent development)


Okay, that second part finally explains it, thanks for that. I had a hunch the five years having been up 2 years ago didn't tell nearly the whole story (though apparently people think I'm crazy for thinking that).


If that was their reasoning, they could do it whenever they were ready and willing after five years. So this explains why they had to do it for five years and might explain why they won't be doing it much longer than that. It might also indicate that cutting off the API was intended but not urgent.


Why would it be so close to the anniversary though? It seems to suggest something else might be going on at the 7-year mark.


Perhaps some people thought you were only nitpicking but I agree and I think it was useful that you asked about this so that we got the discussion leading to a better answer.


I was part of a team developing a travel product which needed huge amounts of data from flights to car rental... My god the travel industry is a mess in terms of accessible data. It was the biggest pain point. API's would randomly change structure, endpoints would stop working with unknown errors, data would be significantly different across companies for the same data etc... It was a shambles. Never again will I develop in the travel industry. Unless you own the data, working with it is terrible.

We ended up building our own little system that merged our own flight data with data from suppliers. The schema some of the suppliers provided was non sensical and it ended up being a really finely tuned system that would break reguarly if one of the data suppliers decided to change it without notice.

I spent my days dreaming of a standardized data pool, and while some of the data was standardized, not enough of it was.

Thank goodness I'm now working in an industry that we can totally own our data and are not reliant on anyone else for it.


Reminds me of my time spent being a customer to a real estate MLS. When industries traditionally rented access to information asymmetry, even if those rents have since diminished, there's a lingering cultural momentum not to "show your hand" by playing nice with information (in addition to these not being organizations with the insight and incentives aligned to be attractive or conducive to IT competence).


I deal with MLSs regularly as part of my current job and this was the first thing that popped into my head when I read the parent comment. They are hell to deal with and we would pay a good amount of money to anyone who could standardize all of them and feed them to us in a consistent format.

Half of the time I spend debugging is on figuring out what is going wrong with different MLSs.


I also deal with MLS data and, on our end, it's in pretty good shape.

Of course, there is a whole department devoted to keeping it clean and consistent, so I don't have to deal with issues that you do.

Now that you mention it, perhaps we should provide an API for MLS data access.


Ive worked with MLS data before. It was terrible. I am currently working with ACH, DDF and I am astounded that our financial system even operates. Because if there is one thing you want in payment processing, it's wildly innacurate and inconsistent data that is lacking documentation.


Fuck MLS. It's supposedly a "standard", but every single MLS API endpoint is completely different. As in, there are very few recognizable similarities between any two feeds. The data structures are not actually standardized whatsoever; one MLS will have all listings in a single "table", while another will have 12 different tables that you have to figure out how to parse and/or join. There is some lingo that is fairly standard because of the industry, but the way the data is organized and represented is wholly unique per MLS. And there is no documentation other than an (optional, usually 2-3 word!) description on each field providing little insight.

The protocol used by MLS servers is kind of standardized... expect not really. There's no single way, for example, to accomplish a full download of an initial dataset. Some MLSes let you order by id with an offset, so you can paginate properly. With others you must use date ranges - but you're assuming that a create or update timestamp is actually meaningful, and surprise - they are not. Some let you run multiple concurrent connections so you can increase data throughput, while others only permit one slow connection that makes it takes 6+ hours to download their entire database.

Finally: good luck figuring out when a record is flat out deleted. The MLS may have a separate table where deleted records are supposed to go, but that table is always empty. The MLS nukes data rows with no way for clients to detect the change other than by downloading the entire database from scratch to find the gaps. This requires running hours of queue jobs PER MLS every 24 hours. It's so ridiculously inefficient.

Yeah... fuck MLS. End rant.


I'm convinced we work at the same company because you just expressed all of the same pain points that I currently have with MLSs at my job. We have to do so many hacky things to make sure that we follow each individual MLSs rules to get them to actually work.

They are absolutely terrible to work with.


I took the liberty of scanning very quickly through your post history. We live and work quite far apart. Seems MLS pain is universal. ;)


And for ACH, it's even worse: you assume success only in the absence of failure. It's shockingly bad.


Not coincidentally these are also industries with the most middlemen.


Mortgages, too...


Didn't like OTA[1], eh?

I don't know that other industries are much better though. Ask a healthcare IT person about HL7.

[1]https://en.m.wikipedia.org/wiki/OpenTravel_Alliance


FUCK HL7! Holy shit, I’ll never get the time back I spent implementing our standard HL7 data extractor and all the other software needed to get that into our billing system. Our poor EDI team has the worst of it though, they’re the ones responsible for mapping all the edge cases various EMR’s (and their per-hospital customizations) into our standard formats.

HL7 claims to be a standard, but it’s a hell of a lot closer to JSON in terms of standardization (that is, a serialization format) than say ANSI X12 (an ugly but generally standard data interchange system).


> Ask a healthcare IT person about HL7.

Been there, done that. Never again!


I liked to say “HL7, standard?” As more of a question.


The car industry is another industry whose data is a series of nightmares. There are a number of services that aggregate inventory data for dealers using them. Sounds great, right? Maybe, if they had halfway decent APIs. Multiple providers--with zero connection to one another, I checked quite carefully after becoming exasperated--somehow managed to independently come to the decision that the best way to make inventory data available was to push large CSV files to an FTP server you setup.

Whatever. People can come up with crazy solutions and you're stuck working with them. At least you've got the CSV files by that point, right? Well, sort of. Turns out they needed a good bit of work. And by a bit of work, I mean that some of them were quite possible the worst CSV files ever generated. And it was...weird. Normally, if there's a problem with a CSV file it's at least consistent across the entire file. Quotation marks not escaped? Ok, no big deal. They're all like that. Usually, you can normalize the data and move forward.

If only. Some lines had escaped quotes. Some didn't. Some lines were actually multiple records because apparently the magic linebreak decided to go on strike. In one case, I kid you not, the file switched from comma-separated to tab-separated. Huh? How'd that even happen? Some values were perfectly valid, just handled in a way that's guaranteed to annoy the hell out of you. But fine. You do what you can, reject the bad (and log to a file for manual review in the hopes that you'll figure...something...out about it), and move on with your sort-of-normalized data. But that's just referring to the data itself, and not the entries.

When you order a new car, the build sheet for every manufacturer is simple enough. Every option has a code. Every option has a name. New car dealers get their inventory data back from the factory and it's plugged into their inventory management systems. Through whatever accidental acts of magic and chicanery, that data eventually makes its way to the data sources you're busy importing. Unfortunately, at some point in the process all of those beautiful factory codes and names--standardized, constant, etc.--disappear. That beautiful "Cobalt Blue" is somehow transmogrified into a very unhelpful "Blue." And don't even get me started on factory options. At times, you're lucky if you somehow accidentally get the basics like, oh, "has two front seats and possibly four-ish wheels." It's even worse with used cars, because some unlucky salesperson/clerk/receptionist/car washer kid had to sit down and manually enter the car data.

Instead of thinking of that giant CSV file as a wonderful list of thousands of cars just waiting to be discovered and purchased, you start to see it as more of a starting point. It's an incomplete list of cars for sale, with some of the information about each car. You need to use other sources to fill in some of the blanks, fix some of the most obvious errors, etc. Luckily, dealers upload their data to as many services as they can. Unluckily, it's often...different across those same source, and it's up to you to figure out what data to keep the same or change. Depending on the manufacturer, you can decode the VIN and pull up all sorts of useful information about how the car's build options. Maybe. You can then use the manufacturer's pricing guide for that model year to fill in the blanks. Assuming, of course, that you've got a copy of the pricing guide in question. Which isn't guaranteed, since they're generally not publicly available (though they do leak...often).

I'm a huge Porsche fan, and I know more Porsche fans. We're all nuts. Details matter. Do you want to know how many [shades of blue](http://paintref.com/cgi-bin/colorcodedisplay.cgi?manuf=Porsc...) Porsche has used over the years? Many of the paint colors are available across different models and different years, so the number is a lot scarier than it actually is, but there are a total of 641 entries in the linked paint database. Someone searching for a used Porsche wants to make certain that they're looking for a specific color or option. They don't want to just use "blue" for their search. They're looking for the gorgeous [Oslo blue](https://gearpatrol.com/2016/08/18/definitive-ranking-blue-po...) imprinted in their minds during a magical childhood moment, damnit. Which was only used in 1961, except for custom paint-to-sample orders in later years. There was 1 993 Turbo S in Turquoise Blue. Jerry Seinfeld bought it. A PTS color will affect the relative value of the car (new or used), so it's one of those fiddly bits that matters a bit.

You'll get another multi-gigabyte CSV file delivered to by FTP on the morrow. And joy, it's not an incremental update with just the new cars. It's all the cars they have data for. If a car has been sold, it'll be omitted from the file. It's up to you to figure out which. Hopefully, the car won't be "un-sold" in a day or two after the buyer backs out. That can get weird, especially when you're dealing with multiple providers. Finally, your simple diff is further complicated by the inevitable likelihood that random data across random listings has been changed as well. Perhaps they caught a typo in the VIN number, or the annoying fact that the paint color originally listed never actually existed.

Needless to say, I sound a bit crazy at this point. Your only option is to accept that, much as it might annoy the hell out of you, there are going to be serious compromises involved with the data you have access to. Apologies to those with sever OCD and perfectionists. Handily, some manufacturers have sites for their dealers (i.e., http://porsche-dealer.com). Usually, these sources are pristine with everything in order. You just need to scrape it where it's allowed, which is its own set of fun.

And don't even get me started on the photos included with listings. It's rare that you'll see decent photos taken by a dealer. Mostly, you'll find those on eBay Motors with certain sellers. Everyone else does their best to make them as terrible as possible. The data providers then take that as a challenge, and crush the ever-living hell out of the image with another round of JPEG compression and give the resulting monstrosity to you at a nice, small resolution. Want something bigger? Forget it.

Maybe I'm blowing all of this out of proportion. Perhaps the industry has changed in the past few years since my experience. Personally, I doubt it. In any case, dealing with this was annoying as hell. This rambling post was oddly cathartic.

Anyhow, if you ask me, I'm pretty sure all of the car search sites just scrape each other; like Ouroboros, depicting a serpent eating its own tail.


>somehow managed to independently come to the decision that the best way to make inventory data available was to push large CSV files to an FTP server you setup.

Somehow this is indeed a standard for data transfers between non-tech companies. (The ones that are sophisticated enough not to use fax or email attachments).


I worked on a team at Microsoft that did the CSV over FTP thing in 2013. So some tech companies do it as well. ;)


My employer has a scheduled job that downloads a CSV over FTP thing at 6PM everyday. This is in adtech, with a company that's about 5 years old.


You know I was thinking as I was reading you guys are crazy for having 641 blues. However I definitely see your point after clicking the links. These are entirely different colors, indeed.


There are (only) a couple dozen different blues Porsche has used over the years. The 641 total is because of how that site lists them by year and model line even though the paint code is the same across them.

It makes more sense when you realize that site's mainly used by autobody repair shops; they're searching by year and model first as manufacturers often use the same name even when it's not technically the same paint (different paint manufacturers, variations in formulation, etc.). That matters with repair work. But for what I was working on, it wasn't relevant.


that was an awesome writeup. I've wrangled finance data and know the pain. Those Porsche blue links are wonderful!


I think this is probably the general state of data exchange systems in most industries/sectors where an IT company/startup hasn't come along to successfully disrupt it or none of the major players have become tech-oriented enough to see - much less sort out - these kinds problems well.

That's been my experience anyways.


Hardly. Most of these things are because the companies in these industries have an interest in having it the way it is. It has little to do with (not) being sophisticated with technology or because some startup hasn't come to save the day. Startups tend to actually have a very small impact on anything generally speaking. It's rare that one blossoms into a Google or Facebook.


IT companies are no better from my experience.


I work in the flight industry and still dream of that standardized data structure...


Seems to me what you describe is a business opportunity. Your business takes on the burden of obtaining the data, and putting it in an easy to use form; for others. There's a company in Pensacola, Fl that's been doing this for years with things like lottery numbers and gas prices.


> Unless you own the data, working with it is terrible.

Heh. Having done work for an airline, I wouldnt even say this.


Ain't that the truth! I tried just messing around with it a while ago to make my own airfare searcher to check a few things for me and it was a mess. Ended up doing the Amadeus sandbox, but the cheapest flights aren't necessarily there and it's a real pita.


How did you integrate all the different schemas? RDF, some kind of rule engine, or plain Java, Python, ... ?


Having worked previously at a company that sounds very similar (maybe even the same one?), our approach was primarily using individually written scrapers and API integrations (when available) in Python, utilizing an underlying scraping framework that predated requests. As you might imagine, these integrations required constant maintenance and were often bug-prone, so much so that the company eventually found itself in the position of outsourcing the work... There were attempts to reduce maintenance through the use of a in-house DSL/rules engine, but ultimately, the range of integrations it was able to support was very limited, and the project was scrapped.


Six months ago, I started developing a Flight Alerting service for QPX Express API.

I was always skeptical as to how long would they keep this API running, since it was a byproduct of a previous acquisition.

But I said to myself, wishfully thinking: Why would they shut down this and lose their clients trust in developing with their APIs?

Sadly, I was again proven wrong.


If a client hasn't learned by now, they're not gonna learn from this either.

For niche apis Google has no trust left to burn, because all trust in its products is either already burnt or inflammable.


And yet, there are still a lot of companies using and relying on Google APIs and cloud services. I don't understand why there is still so much trust in them after they've shown multiple times they will terminate services with little warning. And no, I don't consider 1 year a long enough warning for something that has no clear drop-in substitute.

If you're using a Google service, you must be prepared for when they'll pull it from under your feet. And if you need to prepare for that, why use that service to begin with if an alternative exists?


Isn't that true of ANY company relying on some service from some other company? What makes you so sure that this alternative service is more likely to stay around than one of Googles?

The reason we think that Google EOLs so many more APIs than other companies is because Google itself is still around. Some other company's API wont be EOLd, instead they will just go out of business (or they will be bought by someone who will shut down the service).


Also known as survivorship bias. You don't see the failed companies with dropped APIs because the company disappeared.


Are you going to invest into a company that has such an API its bread-and-butter, forced by finances to continuously improve it, or into a company that has it as a shiny new toy and throws it into basket when something else becomes more shiny?


You mean a company like ITA, for example?


If you're using any service that's absolutely required for business, then you must be prepared for when they'll pull it from your feet or increase the pricing to eat all your profit margin.

Of course you need to prepare for that, that's just basic part of running any business, software or not. The answer to "why use that service to begin with if an alternative exists?" is likely based on cost or quality, but if it's required for your business and you can't switch to an alternative within 1 year, then you obviously knew that you should have had started looking for an alternative long ago and start preparations for switching to an alternative, from day one or, more precisely, from the day you decided that this business is worth running at all. The only excuse not to do that if it's a commodity product with clear drop-in substitutes, otherwise you're just sloppy with running a business and/or knowingly taking on risks that your business may suddenly stop - and not because of the API going away (the risk was predictable) but because of your own unpreparedness.

It's the same with any other services. What do you do if your landlord dumps you or the building burns down or goes down in a flood or hurricane or whatever? If your need for facilities is a commodity in a liquid market, then you'll be able to replace them, but if not, if you need something that's not readily available to avoid huge losses then it's your (assuming executive positions) duty to prepare alternatives in time and/or get appropriate insurance. What do you do if your service for accepting credit cards stops working or dumps you for whatever reason? If you're a reasonable business, you have a second, independent contract with all the deals already arranged that you can switch to in a day if not immediately. The same goes for any non-commodity that you need. If a supplier dumping you means just that you have to drive to a store and buy the same thing from someone else more expensively, then you can skip worrying, but if not, then it's on you to safeguard your business with alternatives instead of blaming suppliers for being unreliable. In some cases, the suppliers will actively exploit knowing that you don't have prepared alternatives - if they've got you by the balls, they can squeeze them and get the price and conditions that they want; and if/when you get serious alternatives, then you can get a whole new range of discounts, that's business as usual.


I was looking into this space some time ago. Got a feeling that this offering was quite unique, I don't think other vendors are offering this information with pay-as-you-go arrangements suitable for small projects. (But I might be wrong with this)

Edit: Looks like other comment chain somebody has mentioned an alternative: https://www.fareportallabs.com/Home/DownloadDocs#0


Nit: "inflammable" means "can be set of fire". So does "flammable". Yes, I know.

You want "not flammable", or if you want to be cute you could try "unflammable".


It's because "inflammable" is a loan word, not a conjugate, and "in-" in French, whence comes the word, means what "en-" means here.

Like with most loan words, it's best to just stick to the native word - which is not "flammable" as Merriam tried to invent 200 years ago, but rather "combustible"


But combustible has a very different implication to flammable, which usually means that the substance would catch fire very easily, rather than just being able to self-sustain burning.


Combustible is another French/Latin word.


Looks like the post means 'either already burnt or will be burnt easily'? So what exactly is your nitpick here?


That doesn't make much sense. Why would the easily-burnt trust still be intact at this point? It's a really weird comment if it wasn't supposed to mean "already burnt, or unable to burn".


I read it to mean 'already burnt or can't be burnt.' I'm aware of the definitions of 'inflammable,' but it just made the most sense in the context to interpret it that way.


I can't edit it anymore, but I did mean "unburnable". I realize (now) that "inflammable" comes from "inflame"/"enflame", but "in-"/"im-" has lots of use as a negation. "Invisible", "indivisible", "inconceivable", etc.


Interestingly, I read this the other way: "...all trust is burnt, or about to be burnt."


I think inflammable (or flammable) applies. I think the user is saying the trust is likely to go up in flames.


Sadly true


I was going to release a side project based on QPX Express API that allows comparing prices for a flight in different countries. Guess I won't bother fixing the last details and will just add it to my list of never finished things.


If it is free, and no ads, it is probably not going to stick long


It's not free, it's expensive.


Correction: If it is not resulting in you transferring more data from yourself or others to Google to profit off of, it is not going to stick around long. Google doesn't seem interested in running paid businesses besides advertising no matter how much you are paying them.


Google is definitely interested in "paid businesses". What they aren't interested in is businesses under a billion* dollars.

*Made up and likely exaggerated number


Actually true... Google had amazing robot grasper arms once upon a time. These were much better than anything that was in industry.

The team got killed because it wasn't a "toothbrush test" business


i'm curious why google (and other large companies like that) might not try to sell those sorts of tech internal-startups to other industry players. possibly a lot of hassle, no doubt, but... tens of thousands of man hours and research just get shelved because "toothbrush test" (then... why were some of these obviously-not-toothbrush ideas being pursued in the first place) and no one else gets to benefit?


TIL Larry Page's "toothbrush test" for acquisitions: "Is this something you will use once or twice a day, and does it make your life better?"

http://www.businessinsider.com/larry-page-toothbrush-test-go...


Umm...Google Cloud Platform?


Charging money or showing ads is not a sufficient condition - a better statement is, if it's not profitable, it's not going to stick around long (with exceptions for products that are strategically important to profitable corporations).


"You don't need to take any action. However, if you are actively using this product you may want to find an alternate solution before April 10, 2018."

So, you do need to take action? That's a pretty terrible set of FAQs. They should at least provide a list of alternatives.


For anybody looking for an alternative, there is Fareportal, which has a full featured API for flights with both search and booking ability. https://www.fareportallabs.com/Home/DownloadDocs#0

I'm happy to answer questions as I'm helping several companies switch over to Fareportal at the moment.


Do u have Gate information for live flights?

I am looking for Gate information & Flight schedules by airport.

Ex: I want to be able to query incoming/outgoing flights to Gate-A-10 in ATL today.

-------------

Query to:

find where [Flight DL123] is going next.

[ATL-LAX] -> Landing in 'Gate 10' in LAX

going next to....

[LAX-MIA] -> Landing in 'Gate A1' in MIA

going next to....

[MIA-JFK] -> Landing in 'Gate 1', Terminal 3 in JFK

------------

Gate 10 in Atlanta:

[AA38] SEA-ATL arriving at 6:37A

[AA38] ATL-LAX leaving at 7:45A

(2 hours no flights at Gate 10)

[AA99] JFK-ATL arriving at 9:45A

[AA99] ATL-JFK leaving at 10:45A


Fareportal handles bookings in advance, not really live flight data.


Looks good. I researched flight data suppliers & GDS companies recently for a side project and found them either very expensive (QPX falls in this category - having to pay several cents per query makes it virtually impossible to do anything creative) or lacking coverage for LCCs in Europe, which is my target market.

So naturally I'm quite impressed with Fareportal and will give it a try. I did do a quick search on CheapOair and didn't see Ryanair among the results (although they do have a flight for that route and date). I know they're icky about third parties advertising/[re]selling their flights but there's some suppliers that do carry their flight data (ie Travelfusion, which politely told me to come back once I have a working product, chicken and egg much?).

I'm not keen to book flights on behalf of users at this point since I have a (not thoroughly documented) fear that regulatory matters will make it difficult/expensive to operate an indie OTA but that's TBD.


If you are looking for API access for LCCs, check out http://www.azair.eu/ They are the best, they have availability + pricing + schedule +... data from every LCC that is out there in Europe. I use their regular website myself for all travels within Europe when flying LCCs since they show you split ticketing options as well as do a real search when you enter lets say, from France to XXX (for all airports). Skyscanner does promote the "take me anywhere feature" but it doesnt show you any real availability data, only displays flights other people have searched for.

I also got an email the other day from http://mystifly.com which also promotes LCC but I haven't tested them yet.


It's very painful to redistribute Ryanair, especially if they don't want you to. They even have captchas on their search pages to block scrapers.


Hey there, need flight info for delayed flights in EU ?

My 3 usd subscription to flight stats[1] give me just 3 days history and no room for more fine tunning

[1](https://i.imgur.com/nOjjPjE.png)


Fareportal is not for live flight data, only bookings in advance.


What is Fareportal's pricing? I can't find it.


Price for API calls? Those are free for affiliate partnerships.

The flights pricing itself matches what you would find, for example, on CheapOair.com or OneTravel.com, which are driven by Fareportal's APIs.


I mean, you don't NEED to take any action... if you don't care that your data feed no longer exists.


Yes. I'm sure many, possibly even the majority, of clients subscribed to the API don't have it in active use. There's a bunch defunct side projects out there. This notice likely went out to every account with a subscription to this API.


It seems clear to me -- you don't need to do anything to continue your use of the API (no website to visit, no contracts to sign, etc). But that doesn't change the fact that they are ending the service.

If a developer doesn't know what "After April 10th, you will not be able to access the API" means, I don't now how they could be more clear.


I think it's the wrong time to use the phrase 'you don't need to take any action'. You can say that when it's a new version being released without any breaking changes but not when you're shutting down a service! You must look for an alternative and implement a migration, that is action.


It is even better, as the question is "What steps should I take?", which is a very "just tell me what I need to do, step by step" way to ask this question, and yet the answer doesn't give you any concrete suggestions for what to do now other than "feel am impending sense of doom".

(Though given that Google knows the only people who care are people they likely consider to be competitors--as the whole reason they bought ITA in the first place was to obtain the power that comes from vertical integration--that is likely exactly what was going through their minds when they wrote that: "let's be particularly unhelpful".)


This is one of those cases where "let the market sort it out" is likely the right answer. If someone has an alternative, you can bet they are going to capitalize on this, and Google telling you where to go may actually hurt more than help (who days their suggestion is best?), and if there isn't an alternative, there's not much to say.


Part of Googles killing all of ITA public facing software and keeping the rest to itself. Google purchased ITA in 2010. QPX was used by a lot of online travel companies.[1]

Already canceled was the flight booking software for airlines.

[1]https://en.wikipedia.org/wiki/ITA_Software

oddly the guy teaching the hadoop class is retired from ITA and talked about them a little in class last night.


From the wikipedia entry and the court documents it references, Google was required to make ITA's software available for licensees for five years after the judgement in October 2011.


Does anyone know if they are shutting down their legacy consumer web portal? By which I mean this: https://matrix.itasoftware.com

Please, dear lord I hope not since it's by far my favorite tool to write complex queries to figure out itineraries and pricing for trips.


Also my biggest concern. ITA Matrix is a godsend, and Google Flights does not have feature parity.


I get a Error: SERVICE_UNAVAILABLE when I try to access that.


It's working for me now. Whatever issue they had, it wasn't a shutdown yet.


Skyscanner also recently made it tougher to get at live airfare data through their API[1].

Sad to see providers disappear for this. Not sure what the alternatives are now.

[1] https://support.business.skyscanner.net/hc/en-us/articles/21...


One alternative is Fareportal, which has a full featured API for flights with both search and booking ability. https://www.fareportallabs.com/Home/DownloadDocs#0

I'm happy to answer questions as I'm helping several companies switch over to Fareportal at the moment.


Thanks for the link. Definitely looks like a good alternative to QPX (and Skyscanner since they don’t like to respond to partner applications). There’s also https://www.kiwi.com, which seems to offer a nicely documented partner API.


I think they want to shutdown the matrix[1]. They already discontinued the matrix smartphone app a year back.

I will be truly lost (quite literally) once matrix is unavailable. I plan out very complex trips and only the matrix can do it.

[1] https://matrix.itasoftware.com


I've seen that before but didn't keep it - What's the difference between that and regular google flights?


The power user interface, which lets you specify all sorts of wacky constraints any other OTA can't handle.

https://travelcodex.com/advanced-routing-language-in-ita/


That's awesome, but once you find an itinerary you want, how do you book the flight? Do you usually go to the individual airlines' websites and rebuild the itinerary by hand? Or do you send the 'fare construction' string over to a travel agent?


Depends on the flight, but I usually use a travel agent.

If it's a simple flight, I might use some airline website to book it, but most often for me it's some thing that you can't book at all on the airlines I use. I fly into small rural airports and they simply dot not exist on any major airline's websites.

I give the string to a travel agent and he is able to book the flight no problem.


Thanks. Looks like google flights can do most of it but with gui elements. The one thing it doesn't do which I really like is to be able to specify a layover of 1-2 days, ita does it which is great. (OK I guess I can do it with multi city, but it isn't like the old days where layovers were sometimes a feature not something to be avoided)


To quote myself from a year ago (although Delta and Alaska aren't partners anymore) [3]:

One of the features I like to use a lot is the ability to specify fare classes. As an example, say I want to fly to Tokyo, and I am an Alaska Airlines mileage plan member. Alaska Airlines does not fly to Tokyo, but it has deals with airlines that do. However, sometimes the fare classes are quite complicated. For instance, "Economy" is broken down into many buckets, and not all are created equal. For instance, Delta has at least 13 buckets for Economy, and each 'fare class' awards different amounts of mileage to Alaska flyers [1]:

E: 25% Mileage

L, U, T, X, V: 50% Mileage

H, Q, K: 75%

B, M, S: 100% Mileage

Y: 125% Mileage

If you search on Google Flights, these will all be called "Economy". If you search on most of the other OTA's (Online Travel Agents), you can sometimes find the fare class during checkout or even as part of your search results, but you can't filter on it (Hipmunk is one that does support some of ITA's syntax for these filters, but not all). The buckets aren't always strictly more/less expensive, but they're usually not exposed very easily, if at all[2]. So, you're often left crawling from listing to listing, expanding to see if they are going to get you any miles. (I'll save the debate of whether miles are worth all the effort for another day.)

On ITA, it's not unreasonable to construct a query that says "During the month of November, show me round trips that are between 12 and 19 days that are going from Denver to either Narita or Haneda Airports, which will earn me more than 50% miles on either Delta or American or JAL, but also only ones that connect in Portland or Los Angeles, with no prop planes or overnight stops, and no <50 minute connections or 3+ hour connections". (I wouldn't actually specify all of these stipulations, but they're good for the example! :) )

[1] https://www.alaskaair.com/content/mileage-plan/how-to-earn-m...

[2] Delta, to its credit, does allow you to search by minimum fair class on its advanced search)

[3] https://news.ycombinator.com/item?id=12740701


I also use routing code to force long layover (e.g. go from Europe to SF via London, and spend the night in London to visit friends, on the same ticket).


Theoretically you can still do that with the multi-city search tool on Flights. It should consolidate back down into a single fare if stopovers are permitted.


Nice, good to know!


Aside from what other people have mentioned: I use ITA because it lets me see the fare rules, which helps me anticipate potentially useful mutations to my ticketing. (For example: Knowing that a particular round trip to Paris allowed for a free stopover in London allowed me to attend a conference in the UK for a much lower cost than if I had booked a round trip ticket to the UK.)


Likewise. I would gladly pay to continue using Matrix. I can't imagine planning flights without it.


Or it will be like Google Voice, on CPR for years, then resuscitated. You just never know.


I really hope not. I'm in the same boat (plane?) as you.


Try kiwi.com? It's not as good I'm, but is fairly full featured.

You can also use a spreadsheet to generate search urls for Google flights.


The features I most need are: routing options, fare class codes and multi-month fare calendars. Only Matrix has all 3 as far as I know.

Often, when I call the airline to book a great itinerary I found on Matrix, the airline won't believe the time/price. I'll have to convince them to trust me and make an itinerary from the flight numbers. It's often faster and cheaper than anything on the airline's websites.


you've probably seen it already but bookwithmatrix.com is also very useful to get pricing based on ITA fare quotes.


I don't think this necessarily signals the end of Matrix ITA. In fact, QPX Express and the Matrix are completely unrelated.

And, "QPX Express was a lower-touch way to let companies start experimenting with QPX without needing full on biz-dev contract cycles", per someone I know with some inside knowledge.


I used to use Matrix but stopped using it after finding that a lot of the time it doesn't actually catch certain deals available only on airline websites themselves. Now I'm back to individually searching every airline website.


It recently received a slight update and has been working better. My understanding is that developers are still actively monitoring it.


Google shuts down a project. I don't think this really stops the press anymore. I'm not familiar with this one, but building your infrastructure on small Google APIs is starting to seem foolish.


> I'm not familiar with this one, but building your infrastructure on small Google APIs is starting to seem foolish.

Maybe you should be familiar, this isn't a Google API, it came through an acquisition and would have been shut down a long time ago if the government didn't mandate them to keep it available. Anyone who knew anything about this API already knew that this was just a matter of time.


Frankly you'd be an idiot to build a business on top of Google services anymore. Just can't rely on anything being around for however long.


One day Google will shutdown Gmail.

Finally then everyone will learn to ignore their non-Advertising services. It's for the best!


This has crossed my mind. I’m a G Suite customer (paid Google docs / gmail etc) and Google makes me nervous the way they shut things down constantly.


GSuite is a perfect subscription business model; they are giving you stuff you will probably never need or use along side something you were already using for free. The cost of a single account is just about small enough to be negligible for a business customer.

This is enough to give me confidence that it isn't going to be shut down.


Wave would have made a nice additional to that suite. I miss Google Wave.

I've built 3 projects that relied on Google services/APIs; none of them exist anymore. I will never build another Google based product as long as I live.


It’s paid. I’ve never heard of Google shutting down paid services.


The post we're commenting on right now is about Google shutting down a paid service


google site search, but i'm sure there have been some others.


My guess is that they are making peanuts selling the API service vs. the handy-dandy rich snippet which allows you to buy tickets (airline, hotel and coming soon packages) right from the SERPs.


Or https://www.google.com/flights/


Well, that's terrible. This was the last(?) API that you could sign up for without negotiating with a clearinghouse (which includes contracted numbers of tickets to sell).


A growing number of airlines/airline groups have their own API too. Some of them are quite limited, others are quite good. API limits are generally low unless you beg (or so it seems)

- Lufthansa: https://developer.lufthansa.com/docs

- IAG (Iberia/British Airways): https://developer.ba.com/

- AirFrance/KLM https://developer.airfranceklm.com/

- Turkish Airlines: https://developer.turkishairlines.com/

Many of these all seem to use the Mashery API portal, so I'm guessing it was sort of pitch by Mashery and/or Sabre. Lots of these APIs seem like a trial of airlines trying to get out from under GDS/clearinghouse systems...


Iata's been working on something for the last couple (5) of years --> http://www.iata.org/whatwedo/airline-distribution/ndc/Pages/...

in 2017 alone they've organized 3~5 hackathons, my bet is that there is LOTs of money to make it grow

(disclaimer : Paris IATA hackathon atendee and chosen project)


So is this a new opportunity for someone to fill this need, or this is a really hard service to offer?

As per other comments: doesn't seem to be much choice in the space anymore.


It's hard.

ITA had the best and brightest, and while they had great success with their shopping engine, no (notable) takers on their airline reservation system. It was likely a good product, but you are chasing a small pool of customers, many of them with low margins. Switching res systems is notoriously time consuming and expensive.

In the meantime, Sabre, Amadeus, etc, improved their shopping engines. Not as good as the ITA offering, but "good enough", and bundled with their res system.


Hard service to offer. The guy who originally built this and sold it to Google has posted on HN a few times about the intricacies of the industry.


Just did a little sleuthing and see that it was ITA[0] that Google acquired in 2010/11.

Also I found this person on HN that looks like the guy you mentioned?[1] Lots of interesting comments for bedtime reading there.

In any case, It's pretty clear that this is not some small insignificant service, which makes this somewhat blazé announcement of it's imminent shutdown (just find another service!) all the more infuriating.

[0] https://en.wikipedia.org/wiki/ITA_Software

[1] https://news.ycombinator.com/threads?id=dmbaggett


It's quite possible that if you have large pile of money you can still get it (https://www.itasoftware.com/ has list of existing customers, and Sales button at bottom - I have no reason to think that customer list isn't still valid.) And at a very minimum Google is using this for Google Flights, that's what they bought ITA for.

There's other companies that will sell you the data, if you have a large pile of money (Sabre, Amadeus, etc.).

So it's problematic insofar as they're making it much harder for random small companies and hobbyists to get it. On the other hand, pre-acquisition this public API didn't exist. So it's not clear Google's acquisition of ITA made things worse in any way.

(Disclaimer: used to work for ITA. Have no inside knowledge of how things work now.)


As someone who worked with the guy being mentioned and has heard some of the stories: It is indeed INCREDIBLY difficult to create this service, for a multitude of reasons. Ones that I can remember off the top of my head: - Every company with flight information is insanely possessive of this information. It can take a long time to actually gain access to it. - The information might be stored on literal magnetic tape, so you need to have a reader for that to even access flight information. (and they're not cheap) - The rules for everything are insane, and completely different across every flight provider. Stuff like a ticket number/ID/whatever it was has complex rules built into it to understand what they mean. - The search space for figuring out an optimal flight from Point A to Point B is VERY complex. He described it as almost driving their most talented engineer insane from trying to figure out how to optimize the search and make it actually work well. (and that doesn't even take into account finding the return flight as well)

I'm sure there were other things mentioned, but those are the ones I remember. If you want to try to disrupt this space, you'd have to be prepared to invest some good capital into just getting started, on top of actually physically flying to the people who can give you the information you need in order to gain access to it. It will not be easy, and it will not be quick. There's a reason ITA changed the game at the time.


One choice could be Fareportal, which has a full-featured API for flights with both search and booking ability. https://www.fareportallabs.com/Home/DownloadDocs#0

I'm happy to answer questions as I'm helping several companies switch over to Fareportal at the moment.


We used this service for an internal company flight-booking application. Fortunately, we booked all the flights for this year but I guess we'll need to find another solution if we do this again for another year.


What I still have problems to understand with, who really used QPX Express? I looked at it several times over the year and it basicially only lets you search for flights (oneway, roundtrip, open jaw) but without any "advanced routing codes" But those are the most important ones since you can specify booking class (not to be mistaken with cabin class), operating, marketing carrier, base fare code, layovers, aircraft type,...

Basicially QPX Express was always a paid and also very limited version of matrix.itasoftware.com

Instead the results were much better (and free) just scraping ITA and being able to enter all those advanced routing codes. Great way for finding error fares, fuel dumps, ... And there was no spam check from google's side, no IP request restrictions, no limit, nothing, whatsoever. The code is a bit hard to go with when they changed to ITA v3 but once you figured it out (and it took us only 2 days since we had a working scraper for the previous version) to adjust it to the new code.


And for anyone just needing flight, availability, schedule date and having problems to structed standardized data, isn't that what the GDS is for (Amadeus, Sabre, Worldspan,...) There you have almost all carriers (excl. some LCCs), have all the data (availaiblity, schedule, pricing, ...) and its either cheap or free to access. Just have a look at https://developer.sabre.com/docs/read/REST_APIs for example. You don't even need a real GDS account with an office ID, just an API access account.


ITT: Most industries are really bad at sharing data in a standardized manner.

This isn't really that surprising considering that there aren't that many IT trade groups for specific industries. While I hate sitting in meetings as much as the next guy what this really requires is each industry's insiders forming a trade group and agreeing on coherent[0] standards, anything else and we'll be back here next week/month/year complaining about the same thing.

[0]And of course this is where it all falls apart if you can form that trade group, a lot of this hinges on the people acting against their nature, unfortunately.


Stupid Question (I work for Google):

Why not move to QPX Enterprise, which continues to be supported? https://www.itasoftware.com/


I almost put significant time and energy into building a product on top of this.

I suspect I will never ever ever use GCP for anything important.


This is not part of GCP, and there's tons of big companies [0] like Spotify, Snapchat, Ubisoft... relying on GCP. Google closes projects that are not working, this one probably wasn't. What's the risk with GCP? That they will just give up on Cloud, the department that is growing the fastest? [1]

[0] https://cloud.google.com/customers/ [1] https://www.inc.com/business-insider/google-alphabet-earning...


Does anyone know a good API for schedules? Most focus on fares which are much more complicated (routing, agreements, availability). I'd like to just get the information of which flights are scheduled. The information is readily available from airports and airlines but so far I haven't found an (appropriately priced) API.


Does anyone know if they will come up with an alternative service? Will flights.google.com continue to exist?


Google: "You don't need to take any action."

Department of Justice: "Hold my beer."


Sorry if this is an obvious question, but does that have anything to do with https://www.google.com/flights for airfare comparison shopping sub site?


Afaik, they use the same underlying data - this is just Google cutting off public access to this data via the API.


Any alternative API?


Check out Fareportal, which has a full-featured API for flights with both search and booking ability. https://www.fareportallabs.com/Home/DownloadDocs#0

I'm happy to answer questions as I'm helping several companies switch over to Fareportal at the moment.


A growing number of airlines/airline groups have their own API too. Some of them are quite limited, others are quite good. API limits are generally low unless you beg (or so it seems)

- Lufthansa: https://developer.lufthansa.com/docs

- IAG (Iberia/British Airways): https://developer.ba.com/

- AirFrance/KLM https://developer.airfranceklm.com/

- Turkish Airlines: https://developer.turkishairlines.com/

Many of these all seem to use the Mashery API portal, so I'm guessing it was sort of pitch by Mashery and/or Sabre. Lots of these APIs seem like a trial of airlines trying to get out from under GDS systems...


I am not aware, at least not of one which is offered for free (one a base level). I have been using this one for Python practice. Sad to see it go.


My company xmltravelgate.com offers a flight API (search & book) with many direct airlines (low cost and NDC) and 3 GDS already integrated, although you do need a contract with them... We're releasing a new aggregated flight API and flight cache API (only price & availability, no booking, no contracts) based on GraphQL scheduled for January. Feel free to contact me for more details.


This is me contacting you. Please share details, very interested.


Please send email to info at xmltravelgate.com and mention HN, thanks!


When you build your house out of sticks (other people's cloud apis) can you really get angry when the big bad wolf comes to blow it down?


Bad analogy. Here you are building your house relaying on services you cannot provide yourself (Water supply, electricity),

You could at least feel a bit betrayed.


There are guarantees associated with water and electrical services, and their sudden disappearance is grounds for riots and civil unrest. Cloud services are not conceived or configured for durability beyond financial stability, which makes them inherently unstable. A poor foundation for anything you want to last or not be bothered with.


Not really. I never signed a SLA with my power or water company. We know they try to keep the service(s) "up"... but if they can't, they can't.

Sadly, people riot and fight over much less than the loss of an API... just wait until black friday or some team wins or loses a game.


> I never signed a SLA with my power or water company. We know they try to keep the service(s) "up"... but if they can't, they can't.

In Italy, these services must be provided by law. Even small mountain towns where it's not profitable to provide the service must be covered. I'd be very surprised if this wasn't the case in any first world country.


I think you might be misunderstanding. You're seem to be talking about how much coverage is required for utilities. The person you're responding to appears to be specifically talking about the (lack of) guarantees for uptime, recovery, etc... for someone who already has service.

In the US, required coverage mandates are up to individual states to set and varies.


You are right. Especially if the API's are provided free of charge.


Can someone identify what apps/services/sites are affected by this? Like Kayak or Hipmunk?


Google shutters another service. Colour me surprised.


Google throws another product under the bus, hardly news by now, surely?


QPX is the biggest Common Lisp codebase I have seen in a commercial product. I left Google years ago, so I wonder if it’s still written in Lisp.




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

Search: