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

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

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.)

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
Parameter 400 Bad Request Invalid parameter
Nodata 404 Not Found We have no data for this request
ServiceUnavailable 503 Service Unavailable Server error
Encoding 400 Bad Request Character set encoding error
Outsidegeographicarea 422 Unprocessable Entity The location is outside the geographic area supported by the product.
Format 400 Bad Request Invalid formatting
Permissiondenied 401 Unauthorized Permission denied
Doesnotapply 400 Bad Request Requested operation does not apply
Internal 500 Internal Server Error Something inside me broke
Outsidetimerange 404 Not Found I have no data for the requested date/time
Validation 404 Not Found Validation error
Accesscontrol 401 Unauthorized Access control error
Unexpectedmissingdata 502 Bad Gateway I cannot find my data

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.