Introduction

This is version 3 of the MET Weather API. For a list of changes since version 2, see the Release Notes for v.3.

The weather data API is loosely based on the REST style of web service programming. All queries are done via HTTP GET, and the results are returned as either XML or the binary format appropriate for the data, as documented by each module.

For additional information, please read our F.A.Q

Available products:

Product Version Also Description Available Schema Swagger Healthz
Errornotifications 1.0 Error notifications from the WeatherAPI system
ExtremesWWC 1.2 The Wettest, Warmest and Coldest places
Forestfireindex 1.1 Reporting danger level of forest fires.
Geosatellite 1.4 * Images from geostationary satellites
Gribfiles 1.1 Serve grib files on the coast from Oslo and Western Norway
Icemap 1.0 Maps as images showing current ice conditions in the arctic regions.
Lightning 1.0 lightning data delivered in UALF
Locationforecast 1.9 Weather forecast for a specified place
LocationforecastLTS 1.3 Weather forecast for a specified place, long term support.
MetAlerts 1.1 Weather alerts from the Norwegian Meteorological Institute
Metgc 1.0 Deliver meteorological forecast data in METGC format for defined areas
Metgm 1.0 Deliver meteorological forecast data in METGM format for defined areas
NLAroutes 1.0 Vertical cross sections for flight routes
Nowcast 0.9 Nowcast for a specified place.
Oceanforecast 0.9 Ocean forecast for a specified place
Polarsatellite 1.1 Images from satellites in polar orbit
Probabilityforecast 1.1 Probability forecast for a specified place
Radar 1.5 Radar images from various locations
Radarlightning 1.1 Radar images from various locations
Sigmets 1.0 Get sigmets and airmets for Norway
Spotwind 1.0 1.1 Spotwinds in XML
Subjectiveforecast 1.0 Forecasts and analyses charts from the meteorologist
Sunrise 1.1 2.0 When does the sun rise and set for a given place?
Tafmetar 1.0 Receive Taf/Metar from airports
Temperatureverification 1.0 Verification of temperature forecast.
Textforecast 1.6 Textual weather forecast for all parts of the country
Textlocation 1.0 All available textual forecasts for a given point.
Tidalwater 1.1 Tidal water information
Turbulence 1.1 Turbulence prognosis
UVforecast 1.0 A prognosis of UV radiation
Upperwindweather 1.1 Upperlevel wind and weather charts
VerticalProfile 1.1 Vertical profiles of wind and weather
Weathericon 1.1 deliver weather icons.

This list is also available in XML format.

Data restrictions

We have a few cases with data that are not freely available. This is marked in the documentation for each product, under the heading Restrictions.

Versions

We recommend reading the section about error handling.

Since a product can change its API, there is a version number as part of every product URL. If you try to use a product version which is deprecated, you will get the data you expect, but with the HTTP status code 203 Non-Authoritative Information. It is important for client software to accept 203-responses, but you should implement appropriate checks or alarms on the return codes.

After a period of being deprecated, versions will be end-of-lifed. When this happens, asking for these versions will be treated as an error, as described in the section about errors. See the changelog for each particular product to find information about the end-of-life date for a deprecated version.

For information regarding API updates, changes to our terms of service, and other important notifications, please sign up for our developer mailing list. This is a low-traffic list, used only by MET Norway to contact users of the API. Please subscribe by sending an email to api-users-request@lists.met.no with the word "subscribe" in the subject line.

The purpose of the version number scheme is to provide a stable interface for devices and software to use, since we are able to handle the changes we can't avoid making in a graceful manner. The goal is not to change the interface often or indeed at all.

Actions

These are examples of how to interface with the fictiocious product dummy (these are not working links since the product doesn't exist).

Errors and return values

Sometimes things don't go as planned. The API will return a (hopefully) explanatory message, formatted as HTML (if using a browser or sending an Accept: text/html request header), otherwise as plain text. In addition you can also check the HTTP status code and the X-ErrorClass response header when using an automated client.

HTTP status codes

200 OK - On success, the appropriate data will be returned with the HTTP status code "200 OK". This data may be XML or some other format (like PNG, GIF or JPEG), but as long as the status code indicates success, they should be there.

203 Non-Authorative Information - The product version you are attempting to use is deprecated. Please consult the product documentation page for information on how to use the upgraded product. Deprecated products are EOL's after a certain period of time - this date is available in the product documentation

304 Not Modified - Client Side Caching is supported on our API servers, and requires the use of the if-modified-since directive to be sent in the client request header. For more information, please consult the http protocol specification at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html for more information and an example of how to correctly send this request

400 Bad Request - On error, the HTTP status code "400 Bad request" is returned along with an error message formatted as HTML. Other 4XX-codes may be added in the future to differentiate errors. In other words, a client expecting binary data (like images) should not attempt to parse, decode or use the data returned to it if it got a 4XX code.

404 - If the request is OK as such, but the product handler does not have any data to offer, you will normally receive a "404" code. However, these are cases where empty response data (ie. an XML document with no real content) do make sense. In these cases, it can be impossible for the WeatherAPI to see if the input data it gets from the weather models is empty because of an error, or because it really should be empty.

422 Unprocessable Entity - The HTTP status code "422 Unprocessable Entity" might be returned when the request is syntactically correct, but the semantics of the specified url parameters make it impossible to return data. E.g when you specify a location outside the supported geographical area for the product. (Note: In hindsight this is probably not correct usage of 422 as it is meant for WebDAV, but sometimes it is more important to be consistent than correct.)

429 Too Many Requests - The HTTP status code "429 Too Many Requests" indicates that the user has sent too many requests in a given amount of time ("rate limiting"). Our Terms of Service state that over 20 requests/second is defined as heavy traffic, which is not allowed without permission.

499 Client Closed Request - The HTTP status code "499 Client Closed Request" is actually a client error, indicating that the client terminated the connection before the response was finished (presumably due to a timeout).

500 Internal Server Error - An unspecified error in the API itself. Could possibly indicate a bug in the code (horror!), but more likely a deployment or server problem.

502 Bad Gateway - The API could not fetch data from the backend, either from disk or one of several internal webservices.

503 Service Unavailable - The service is currently not operational or functioning properly. Examples include a radar site being down, or a service is not configured.

ErrorClass header

In addition to the HTTP Status Code the API also returns an X-ErrorClass response header which might explain further the cause of the error. The following codes are currently used:

ErrorClass Status Code Description
ErrorFromBackend 502 Bad Gateway Backend error
Internal 500 Internal Server Error Something inside me broke
Encoding 400 Bad Request Character set encoding error
ServiceUnavailable 503 Service Unavailable Server error
Parameter 400 Bad Request Invalid parameter
Validation 404 Not Found Validation error
Format 400 Bad Request Invalid formatting
Permissiondenied 401 Unauthorized Permission denied
Ratelimitation 429 Too Many Requests Traffic rate limitation
Outsidetimerange 404 Not Found I have no data for the requested date/time
Unexpectedmissingdata 502 Bad Gateway I cannot find my data
Doesnotapply 400 Bad Request Requested operation does not apply
Accesscontrol 401 Unauthorized Access control error
Outsidegeographicarea 422 Unprocessable Entity The location is outside the geographic area supported by the product.
Nodata 404 Not Found We have no data for this request

This list is non-exhaustive, additional codes can be added over time (normally implemented in future versions).

Note that Unexpectedmissingdata returned a 404 in the old (version 2) API. This was changed as it really is not a Client Error but an error in the backend, but that was impossible for the user to discern.

Parameters and data type definitions

Parameters are specified as normal GET request query string parameters.

Note that according to the new HTML5 specification, semicolon is no longer accepted as a valid parameter separator. The standard states that implementors should be "strictly splitting the string payload on U+0026 AMPERSAND characters (&)". The use of semicolon separators is hence deprecated in all new WeatherAPI products and version released from August 2016 onwards. For compatibility we will try to honor old requests as long as practically feasible.

This is the complete set of data types accepted by the WeatherAPI modules. The documentation for each product will refer to these data types. Note that the only character set allowed in the input parameters/URLs is UTF-8.

Data compression

Data of MIME types text/html, text/plain and text/xml are gzip encoded, if the client requests this in the HTTP headers.