Google is shutting down the QPX Express API for airfare data
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
196 comments
[ 1.2 ms ] story [ 224 ms ] threadI'm happy to answer questions as I'm helping several companies switch over to Fareportal at the moment.
- 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...
So, you do need to take action? That's a pretty terrible set of FAQs. They should at least provide a list of alternatives.
(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".)
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'm happy to answer questions as I'm helping several companies switch over to Fareportal at the moment.
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 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
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)
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.
I also got an email the other day from http://mystifly.com which also promotes LCC but I haven't tested them yet.
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...
I'm happy to answer questions as I'm helping several companies switch over to Fareportal at the moment.
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
You can also use a spreadsheet to generate search urls for Google flights.
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.
https://travelcodex.com/advanced-routing-language-in-ita/
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
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.
- 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...
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)
As per other comments: doesn't seem to be much choice in the space anymore.
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
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.)
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.
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.
I'm happy to answer questions as I'm helping several companies switch over to Fareportal at the moment.
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.
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.
For niche apis Google has no trust left to burn, because all trust in its products is either already burnt or inflammable.
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?
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).
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.
You want "not flammable", or if you want to be cute you could try "unflammable".
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"
Edit: Looks like other comment chain somebody has mentioned an alternative: https://www.fareportallabs.com/Home/DownloadDocs#0
*Made up and likely exaggerated number
The team got killed because it wasn't a "toothbrush test" business
http://www.businessinsider.com/larry-page-toothbrush-test-go...
You could at least feel a bit betrayed.
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.
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.
In the US, required coverage mandates are up to individual states to set and varies.
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
2018 - 2011 = 7?
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.
https://news.ycombinator.com/item?id=2424592
https://news.ycombinator.com/item?id=2992660
(Algolia's HN search is invaluable: https://hn.algolia.com/ )
- 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
Yeah, sure.
Google is heading Microsoft 199x way - fastly becoming public enemy no 1.
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.
Also, I can't take you seriously when you're saying that Google can do considerably more global damage than IS. Think a little bit more before speaking. IS has directly been responsible for hundreds of thousands of deaths and many more injuries, and has severely curtailed the rights of millions of people in the afflicted regions that it took over. Those are all people like you and I, and what happened to them matters. There's just no comparison between that and you losing access to some API. Boo hoo.
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.
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.
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 :)
> 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
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.
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.
They are absolutely terrible to work with.
Half of the time I spend debugging is on figuring out what is going wrong with different MLSs.
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.
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
Been there, done that. Never again!
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).
That's been my experience anyways.
Heh. Having done work for an airline, I wouldnt even say this.
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-...
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.
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).
Finally then everyone will learn to ignore their non-Advertising services. It's for the best!
This is enough to give me confidence that it isn't going to be shut down.
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.
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.
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.
I suspect I will never ever ever use GCP for anything important.
[0] https://cloud.google.com/customers/ [1] https://www.inc.com/business-insider/google-alphabet-earning...
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.
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.