API Concepts

Frost is a RESTful API that provides access to MET Norway's archive of historical weather and climate data. This page contains useful reference documentation related to usage of the API. Contact us if you have more detailed questions.

  1. Getting started.
  2. API version
  3. Authentication
  4. Authorization
  5. Weather and climate element identifiers
  6. Calculation method
  7. Time specification
  8. Relationship between referenceTime, timeOffset, and timeResolution
  9. Geometry specification
  10. Search filter
  11. JSON filter
  12. Resources, schema, parameters, verbs
  13. Hypermedia
  14. CORS
  15. Localization
  16. Mailing list

Getting started

The Frost API is primarily for developers who need to develop scripts or applications that access MET Norway's archive of historical weather and climate data. The API is easy to use; all you need is an e-mail address.

To get started using the Frost API:

  1. Request your client ID and client secret on this page and store them in a safe place. (Side note: While analogous to user name and password, the client ID / client secret is really a different concept. For starters, user name and password are typically defined by the user rather than being auto-generated by the API). Note that the client secret is only required in certain cases to get access to restricted data. Many users will only need the client ID.
  2. Play with and learn more about the resources available in API Reference. The client ID must be copied into a special field near the top of the page before issuing requests.
  3. Begin developing your application. All calls must be authenticated with your client ID. To authorize access to restricted data, you require an access token acquired through the OAuth2 client credentials grant (as well as permission to access those resources). Note that the vast majority of data on this service is open, so the authorization flow is only rarely required.

The client ID is used to identify your application. There are currently no hard data retrieval limits on use of the API (these may come later). A client ID that places undue strain on the server infrastructure during this period may be deleted without prior warning.

API version

The Frost API is currently in version v0 and will remain so until a proper procedure for handling version updates is in place. Please refer to the NEWS section on the toplevel page for the current status.


The Frost API requires all requests to include a client ID to authenticate. You pass the client ID to the API using basic authentication. Using curl, this can be done as follows:

    curl -i --user YOUR-CLIENT-ID: "https://frost.met.no/tests/secureHello"

Note the punctuation after the client ID, to indicate an empty password field.

In the API Reference, you can paste the client ID into a special field near the top of the page in order to authenticate calls. Alternatively, if you try to access a resource call without authenticating, the browser will usually pop-up a credentials dialog where you can paste the the client ID into the username field (leaving the password field empty).


The authorization feature is currently not implemented. Only free data is available.

Weather and climate element identifiers

See an overview of the available element identifiers (IDs) in the Table of Weather and Climate Elements (experimental!). The IDs are defined for use in Frost API and are, as far as possible, based on CF standard names and structured as a Calculation Method.

Calculation method

A calculation method defines in detail how a particular element is derived, typically by combining statistical functions in different ways.

The following combinations are currently available:

<base name>air_temperature
<method>(<base name>)accumulated(precipitation_amount)
<method>(<base name> <period>) best_estimate_sum(precipitation_amount P1M)
<method>(<base name> <period> <addition>) mean(air_temperature_anomaly P1M 1961_1990)
<method>(<inner method>(<base name> < inner period>) <period>)mean(max(wind_speed P1D) P1M)
<method>(<inner method>(<base name> < inner period>) <period> <addition>) integral_of_deficit(mean(air_temperature P1D) P1M 17.0)

where the components are defined as follows:

base nameThe primary quantity. Normally this is a basic physical quantity. It is normally in accordance with the CF standard name table or CF guidelines for construction of standard names.
methodThe main method (function), applied either directly to the primary quantity or indirectly via an inner method.
inner methodThe inner method (function), applied directly to the primary quantity and used as argument to the main method.
periodThe period over which the main method is applied. This is an ISO 8601 duration such as P1D (one day) or P1M (one month).
inner periodThe period over which the inner method is applied. Also an ISO 8601 duration.
additionEn extra, context-dependent quantity applicable to the main method. It could be a numerical threshold (like 17.0) or a reference period (like a normal period of the form <from-year>_<to-year>, e.g. 1961_1990).

A more detailed description of the various calculation methods is available directly from the elements endpoint.

Methods and time periods correspond to cell methods and time bounds in the CF convention.

Available timeseries

Each data value from availableTimeSeries has parameters as shown in the following example:

    "sourceId" : "SN10380:0",
    "level" : {
      "levelType" : "height_above_ground",
      "unit" : "m",
      "value" : 2
    "validFrom" : "2005-01-04T00:00:00.000Z",
    "timeOffset" : "PT0H",
    "timeResolution" : "PT1H",
    "timeSeriesId" : 0,
    "elementId" : "air_temperature",
    "sourceId" : "SN10380:1",
    "level" : {
      "levelType" : "height_above_ground",
      "unit" : "m",
      "value" : 2
    "validFrom" : "2005-01-04T00:00:00.000Z",
    "validTo" : "2006-01-31T00:00:00.000Z",
    "timeOffset" : "PT0H",
    "timeResolution" : "PT6H",
    "timeSeriesId" : 1,
    "elementId" : "air_temperature",

sourceId: SN<station identity number>:<parallel sensor number>. The recommended official sensor has by default parallel sensor number 0, unless the user specifically requests a parallel sensor. Periods with parallel sensors are typically used in the process of replacing an old sensor with a new. SN<station number> is by default alias for SN<station number>:0

level: Used for weather parameters which are measured at different heights or depths

validFrom: Start of (this part of) the time series

validTo : End of (this part of) the time series. Note that even though a time series may be split into several parts by the end point availableTimeSeries, the entire time series with SN<sensor number>:0 and timeSeriesId:0 can independently be retrieved by the end point observations as one long time series.

timeOffset: Observation time relative to midnight.

timeResolution: Period between each data value, i.e. data output frequency. P1D means once a day. PT6H means data values every 6th hour. If the timeResolution differ between night and day, the shortest timeResolution is given.

timeSeriesId: 0 or 1 where :<parallel time series number>. The recommended official time series has by default "timeSeriesId": 0, and is provided unless the user specifically requests "timeSeriesId":1.

elementId: Weather element identity

Time specification

The Frost time specification is based on UTC time and ISO-8601, extended with repeating intervals which do not exist in the ISO standard.

NOTE: Intervals follow standard inclusive/exclusive semantics; i.e., [0,1) representing a value that is equal to or greater than 0, and less than 1.

As per the ISO standard, repeating time points are repeated immediately after each other. So, for example:


Represents the four consecutive time intervals:





For repeating intervals, we add a duration that represents the time between the start points of the interval. So for example:


Represents the four time intervals (separated by a duration of 1 day):





NOTE: As a convenience, the time specification may in certain contexts consist of the word 'latest' to request the most recent data.

Relationship between referenceTime, timeOffset, and timeResolution

Each observation value has a referenceTime, timeOffset, and timeResolution as shown in the following example:

      "sourceId": "SN18700:0",
      "referenceTime": "2017-01-01T00:00:00.000Z",
      "observations": [
        "elementId": "sum(precipitation_amount P1D)",
        "value": 0.1,
        "unit": "mm",
        "timeOffset": "PT6H",
        "timeResolution": "P1D",


TimeResolution is the period between each data value, i.e. data output frequency. P1D means once a day.

TimeOffset is observation time relative to midnight.

Case 1: Observations with timeResolution < 1 day

Observations with shorter timeResolution than 1 day, are generally stored with date and time in the data storage. The referenceTime is then equal to the observation time, and no timeOffset should be added to referenceTime to get the original observation time.

Case 2: Observations with timeResolution ≥ 1 day

Instantaneous observation values with timeResolution ≥ 1 day are also stored as observations with date and time in the data storage. The referenceTime is equal to the observation time, and timeOffset should not be added to referenceTime.

NOTE: When referenceTime is different from midnight, referenceTime is equal to observation time and timeOffset should not be added.

Case 2.1: Diurnal data

Diurnal data represent a 24 hour period on a specific date. They are stored with date only in the data storage with a referenceTime of the form <year>-<month>-<day>T00:00.

If timeOffset = PT0H, the observation value represents the period from midnight to midnight on the calendar date, i.e. from <date>T00:00 to <date>T23:59.

If timeOffset != PT0H, the observation represents the last 24 hr, at the time after midnight equal to timeOffset. E.g. elementId = sum(precipitation_amount P1D) has timeOffset PT6H. This means that the observation period lasts continuously from the previous date at 06 UTC to current date 06 UTC. ReferenceTime <date>T00:00 is just the specific date for the diurnal value. The end of the observation period, is referenceTime + timeOffset.

Case 2.2: Monthly data

Monthly data are aggregated data. They are stored with observation time as <month> and <year> in the data storage. Day 1 is added to the referenceTime: referenceTime = <year>-<month>-01T00.00, i.e. the date of the first day in the observation period.

If timeOffset = 0, the monthly value represents the calendar month, midnight to midnight. The referenceTime is of the form <year><month>-01T00:00, i.e. the start of the observation period.

If timeOffset != 0, the monthly value represents the period from p1 to p2 where p1 and p2 are midnight + timeOffset on the last day of the previous and current month respectively.

As an example, element ID sum(precipitation_amount P1M) has timeOffset PT6H. This means that the observation period lasts from <year>-<previous month>-<last day of previous month>T06:00 to <year>-<current month>-<last day of current month>T06:00. I.e. the value of February 2018 has referenceTime = 2018-02-01T00:00 and is based on the period from 2018-01-31T06:00 to 2018-02-28T06:00.

Exception: Old monthly minimum air temperature, min(air_temperature P1M)em> from 1894-1937 were calculated using the average minimum temperature of 2 days, and is hence based on the period from <year>-<previous month><last day of previous month> to <year>-<month next month><first day of next month>

Case 2.3: Seasonal data

Seasonal data represent the periods of spring (1 March - 31 May), summer (1 June - 31 Aug.), autumn (1 Sep. - 20 Nov.), winter (1 Dec. - 28/29 Feb.), winter half year (1 Oct. - 31 March), and summer half year (1 April - 30 Sep.).

In this case, referenceTime is set to the start date of the seasonal period, e.g. for spring:
referenceTime = <year>-03-01T00.00

TimeOffset follows the same rules as for monthly data.

Case 2.4: Annual data

Annual data cover the calendar year. In this case, referenceTime and timeOffset follow the same conventions as for seasonal and monthly data.

Geometry specification

Geographic location in Frost is expressed in terms of either a single point or a polygon area. Coordinates are expressed as longitude and latitude based on WGS 84.

Geometry objects in the JSON output follow the GeoJson format, as specified in IETF RFC 7946.

When querying, geometry is expressed using a syntax based on Well-known text:

Syntax Description
POINT(10 59) Refer to the exact point given by the geometry object with longitude 30 and latitude 10 in WGS84 projection.
nearest(POINT(10 59)) Refer to the item closest to longitude 10 and latitude 59.
POLYGON((10 59, 10 60, 11 60, 11 59, 10 59)) Refer to the items inside the polygon starting with longitude 10 and latitude 59 etc. Note: polygons with holes are not supported by the Frost API.

Search filter

The standard search filter is case-insensitive and supports asterisks ('*') to represent zero or more characters.

For example, 'f*n*d' matches 'Finland'.

JSON filter

A JSON filter is a special type of JSON object that consists of zero or more key-value pairs: "<key1>": "<value1>", "<key2>": "<value2>", ... The braces around the object may be omitted, like in this case. Each value is a comma-separated list of search filters.

For example, the request


matches elements with sensor level type height_above_ground and sensor level value 2.


The Frost API provides a RESTful API centered around resources. These resources can be acted upon using the standard HTTP verbs. Descriptions of the available resources can be found in the API Reference.

HTTP verbs

The Frost API attempts to use appropriate HTTP verbs to perform actions on resources.

Verb Description
GET use to retrieve data
POST use to load data to the API (requires Authorization)
PUT use to update data in the API (requires Authorization)
DELETE not permitted at this time


The API currently supports Hypermedia through swagger, via the reference endpoint.


CORS (Cross Origin Resource Sharing)

Currently not enabled.


Currently not enabled.

Mailing list

The following mailing list can be used for posting questions about usage of the API and for receiving important announcements: