Such Weather. Wow.

Popular free weather API from deprecates URLs and adds HTTPS

Christian Skarby from the Norwegian Meteorological Institute (MET Norway) announced some changes to their free weather API today. The API endpoint is to be shut down in just six months from now on the 2016-09-05, but a new replacement API endpoint will open at

The new replacement will take its place and introduces encryption and privacy at the same time.[1] I contacted MET Norway a month ago to inquire about whether they could enable encryption to prevent their API from leaking users’ approximate physical location in the clear. Today’s announcement shows they’re listening and taking security and privacy seriously. Securing this data from potential eavesdroppers is important to users who are hunkered down in a bunker somewhere without the opportunity to look at the weather outside. (Okay, I had some trouble coming up with a better example.)

According to the deprecation plan laid out by Mr. Skarby, the popular will shut down entirely in just six months.[1] This doesn’t give application developers much time to act and we can expect to see some applications break in about half a year either for failing to update to the new endpoint or failing to deliver updates in time. MET’s soon-to-be deprecated API endpoint is used by many weather data libraries such as libgweather used by the GNOME desktop. Some Linux distributions wait years before shipping non-security updates to their Long Term Support (LTS) releases.

The new and the old endpoints were served from the same system. The deprecation seems to come from either a desire to reduce the overhead from operating two or an unwillingness to invest in a multi-domain certificate.

MET Norway provides detailed weather data for 10 million places around the world freely available under a permissive Creative Commons Attribution license.


  1. To clarify: The weather portal is NOT affected. These changes are of interest to application developers and providers consuming the weather api on and the legacy alias

    Both and have been aliases to the same weather API services from MET Norway since NRK and MET officially opened Yr on 19th September 2007. We have for several years seen that most traffic on these weather API services have been requested through, though there still are api-consumers using the alias which is provided for legacy compliance. (Further there is a substantial use of varsel.xml on Varsel.xml and any other API services from Yr and MET are NOT affected by the referenced announcements.) The last 24 hours before we enabled permanent redirect we received 17,8% of the requests on and the rest (82,2%) on Of course this is still a substantial amount given the popularity of our services, however most applications are using We will monitor the usage and encourage everyone to use In fact changing to https provides better security for your application users as the requested positions and our replies then will be transported through encrypted traffic, which is harder to spy on and harder to alter: https provides privacy and integrity.

  2. Stupid Norwegians! My app stopped working and I couldn’t work out why. Guess it was my fault for not following that announcements list. Thank you for sharing details on the blog, and thanks or your informative comment @Christian Skarby.

  3. It was great to read this! Thanks for the heads up!

    On another note, do you know where one can get more information on how gets the forecasts by periods? When one gets the full XML from, based on lat/long, they are not always consistent, offering detailed information on the beggining, then only a few forecasts per day, depending on the location. I wonder if there’s any documentation on how one can predict how many forecasts per day (and at which time) one will have on the XML.

    In order to mimic on my Pebble watch, I had to make lots of calculations to finally make it display the same information on my watch than what is displayed on app, but I’d like to understand better what’s the logic behind period division.

    1. I wonder if there’s any documentation on how one can predict how many forecasts per day (and at which time) one will have on the XML.

      I’ll take a guess that the API provides as much information as is known about any given location at any given time. Depending on when you make the request and for what location you’re making the request, you’ll get varying results.

      The weather is unpredictable, so it stands to reason that a weather API would be as well.

      You could contact MET Norway’s API team (contact details at the bottom) and ask if they have any more details.

Leave a Reply

Your email address will not be published. Be courteous and on-topic. Comments are moderated prior to publication.