General Weather API usage
The MET Weather 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 JSON, XML or the binary format appropriate for the data, as documented by each module.
Note that we only support encrypted HTTPS calls to the API. Any unencrypted HTTP calls might result in a 301 redirect (for convenience when typing in URLs in the browser), but constant HTTP traffic is considered a TOS violation and can lead to blocking.
These are examples of how to fetch data from version 0.3 of a fictiocious product
dummy (these are not working links since the product doesn’t exist).
To fetch data, you specify the an endpoint and a query string after the product root URL:
For some older products, you specify the query string parameters right after the product root URL, without any endpoint:
Note: This practice is being phased out in favour of using specific endpoints.
The product reference documentation can be found using these actions:
https://api.met.no/weatherapi/dummy/0.3/documentation # traditional method
https://api.met.no/weatherapi/dummy/0.3/ # for newer products
Some products supply an ever changing set of data. To find the one(s) you want, you must first download a list of the available data files.
https://api.met.no/weatherapi/dummy/0.3/available (default XML)
https://api.met.no/weatherapi/dummy/0.3/available.json (JSON format)
Note that not all function handlers support this action; some because it doesn’t make much sense, and others because it’s just not implemented.
Check the documentation of the product handler you’re using to see if it is supported. Trying to call it on a handler which doesn’t support it will result in a 404 Not Found error.
An empty resulting list means that the product handler doesn’t take any parameters, but has an available product. Note: This practice is no longer being followed.
JSON schemas are normally included in the OpenAPI (Swagger) feed where available.
For XML data you can download an XSD or DTD using the following action:
Note that the SchemaLocation URL in the XML is usually different, referring instead directly to the authorative MET API schema source:
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 by rewriting them in the frontend proxy.
This is the complete set of data types accepted by the WeatherAPI products, defined as regular expressions. 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.
One or more occurrences of the number 0-9, possibly with plus or minus in front:
One or more of any alphanumeric character plus underscore (_), but the first character must be a letter:
An integer optionally followed by a dot (.) and one or more integers. Possibly prefixed with plus or minuses:
An ISO 8601 date string formatted like this example:
The timezone specifier, Z, is mandatory. Currently, only UTC dates are accepted. This may change.
Some product handlers can deliver the same product in multiple formats, e.g. both XML data and an image. The
content_type parameter lets the client ask for a specific data type from these. This value should be a well-formed Internet media type. Which media types are supported by which product handler should be documented by the handler.
Note: We are gradually phasing out the
content_type parameter in favour of specifying the format as a file extension (e.g.
Every call to the API returns an HTTP status code, like
200 OK or
404 Not Found. It is important that your client checks these codes and take action accordingly. There is a long list of possible values and their explanation on the Status Code page. In addition you can check the
Errorclass response header for a more detailed explanation.
Response body data of the following MIME types are gzip encoded, if the client requests this in the HTTP headers.
You can subscribe to notifications of changes to each product in the RSS format:
The same information for all products is also present in the general API changelog feed: