Google Silently Kills Popular API, Breaks Weather Apps Everywhere

Google Silently Kills Popular API, Breaks Weather Apps Everywhere

If your favourite weather app suddenly stopped working in the last week or so, there’s no point trying to refresh or reinstall it. Google has shut down its weather API without a word and stranded developers who relied on it to power their weather-related applications. What we’re left with is a pile of broken apps that may or may not get fixed.

It turns out that developers using Google’s weather API were doing so without authorisation. The private API was only intended to serve weather data to the now deprecated iGoogle service, but its simplicity made it popular with third-party developers. So while it’s perfectly understandable for Google to close the API along with iGoogle — and it has every right to do whatever it wants with its own API — the lack of communication has left everyone scratching their heads.

There are a few things you can do to try to fix the problem. Some apps offer alternative weather services such as Yahoo or World Weather Online — so have a dig through the app’s settings to see if you can switch the source from Google Weather to something else. If that’s not an option, check the app’s page on Google Play or iTunes or wherever, and then the developer’s website. Warning messages have been added to the descriptions of affected apps in some cases, which means it’s simply a matter of waiting for the developer to push out an update.

If your app is affected but so far unacknowledged, email the developer and ask what’s going on. I know of at least one developer who has made his app unsearchable on Google Play while he tries to fix his app, and another website has shut down altogether. So be prepared to ditch the app and hope that the next one doesn’t have the same problem. Unfortunately, there’s not a lot we can do about developers using unsupported APIs and Google pretending that nothing happened. We’ll just have to keep holding the mess they made.

[TheNextWeb via Programmable Web]


  • >> “the lack of communication has left everyone scratching their heads”

    As you yourself said, it was a private API not intended for public usage. Any programmer worth their salt knows they should not rely on implementation details or private API functionality.

    To be honest, I would be more surprised if there WAS communication about such a change — they happen frequently, and in the vast majority of cases without being noticed by end-users. It’s unfortunate that usage of the API had apparently become popular in this case, but that doesn’t change the facts of the situation: you simply can’t/shouldn’t rely on a private API.

  • Jason is spot on, this always was a private API that you had to reverse engineer in order to use, developers would be silly to base anything but the most trivial of apps on it, and when it’s gone *meh*

    More interesting though: everyone knows that the Google Reader APIs are also private, but used in so many great apps (like Reeder for iOS). Now if Google was to shut those down, expect a riot 😉

      • In this case none… it’s a private API that you SHOULD NOT be using. Why should developers have any obligation to support those who have reverse engineered and made use of an API that was never intended for public consumption?

  • Interesting. This makes me wonder if there wouldn’t be some value to an “API Code of Ethics”. I would like to see companies with public-facing APIs adhere to a set of standards or clear commitments, such as “this API could go away without warning”, “we will give at least 30 days notice if an API is going to be retired”, “We will give at least 2 weeks notice before breaking changes our made to a non-versioned API”, etc.

    Given the extent that large portions of the web rely on these APIs, adherence to an “API consumers Bill of Rights” seems like a good thing both for companies and developers.

    • Not really relevant… this is NOT a public-facing API. Any good programmer should have ASSUMED that “this API could go away without warning”, and that “there will be NO notice of changes to this API”.

  • It’s not a matter of private/public API. Google is a commercial company, so they want to make money. The policy they use is very simple: provide a product/API in beta version, see the user’s response, gain free debug thanks to million of users and, as soon as the product/API is enough mature, sell it.

  • I can tell you what happened. I work at Weather Central, a company in Wisconsin, and just a few weeks ago we were bought by Weather Services International, our previous main competitor. WSI in turn is owned by The Weather Channel Companies (which is owned by NBC, which is owned by Bain Capital and Blackstone Group). The Weather Channel Companies also recently bought Weather Underground.

    We just heard that WSI struck a deal with Google to provide Google with weather data, and the contract terms stipulated that Google would stop offering their weather API so that WSI could sell access to its own weather API — and by that I mean the weather API here at Weather Central. We call it “DataCloud” (clever, right?) and you can find it at I think WSI and Weather Underground each had their own APIs as well, but they aren’t as good, so I think it was our API which sealed the deal here.

    Google’s API won’t be coming back until that contract expires, if ever, and I don’t know when that is.

    The answer to your next question is, yes, you’ll have to pay for access, because in fact providing weather data is expensive (hence my salary). If all you want is the temperature, you can scrape that off of government websites.

    • Interesting… So in the US weather analysis is done by private companies?

      Because in Australia, I think Bureau of meteorology which is a government organisation provides all weather analysis (and including monitoring of natural disasters like bushfires and cyclones). Most news services just get it from them and report it to the public….

      • We have a government weather entity – the National Weather Service. But generally they don’t provide a ton of detail and their report format is archaic. Nor do they hve any kind of API that you can point clients at. So most developers depend on private providers for their API and the fact their data is much easier to parse.

        • Actually if you’re referring to the US, NOAA ( does have a full API with quite detailed information. I just wrote a class wrapper around it that pulls back current conditions and also 3 day forecasts. The current conditions item is a bit of a kluge IMHO as you have to lookup the latitude and longitude for a given zip and then calculate the distance to the 3000+ weather stations to find the closest one, then you get the current conditions from there.

    • In my mind, this is anti-competitive on several levels. I genuinely hope that there are startups that can bring to the table a similar API that meets the same level of awesomeness that Google’s provided (most competitors, even the paid ones, suck greatly in comparison). More than that, I hope that these companies are and remain out of the bubble of crap surrounding WSI and its underlings (including the company you work for, Weather Central).

  • In my case, I installed a weather METARS generator and am working the conversion so I can still use the google weather icons. Basically on the server side, cron run a script every 3 hours to get the lastest data from airport, then my RESTful webApp grabs from that file. still broken but working on it:

  • I’m author of Make Your Clock Widget and I had the same issue with Make Your Clock ( but fortunately I already had YR.NO support implemented so I just simply removed Google Weather API links and it works now.

    After this issue I’m seriously considering opening of Weather API for 3rd party weather providers. It could give my users freedom of choice and it would also make app less fragile in case that YR.NO decides to close their API.

    Major problem with wearher int Android apps is that professional weather data are sold on subscription basis but apps are sold using single time payment. So it caused pricing issue as you need to estimate how long time will user use weather data and include it in price of the product.

    • Hey Tomas Hubalek, if you want to try, I could provide you for testing a URL resource from which you could get reliable weather. From a server application, I now use airport Metars from which I parse data and write it back the way my webApp consumes the XML the now defunct google way. My only issue right now is linking the proper weather icon (now using an algorithm to pin down the right icon) I’m working on it now and should be up and running shortly.

Show more comments

Log in to comment on this story!