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. Available timeseries
  8. Time specification
  9. Relationship between referenceTime, timeOffset, and timeResolution
  10. Geometry specification
  11. Search filter
  12. JSON filter
  13. Resources, schema, parameters, verbs
  14. Hypermedia
  15. CORS
  16. Localization
  17. 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.


Requests for data (typically everything else than static HTML-pages) must be authenticated with a client ID, either by using Basic authentication without a password, or by using OAuth2 in combination with a client secret and an access token. Note: OAuth2 must be used for authorizing access to confidential data, while both Basic authentication and OAuth2 may be used to access freely available data.

Basic authentication

Example using curl:

      curl --user <client ID>: "https://frost.met.no/observations/availableTimeSeries/v0.jsonld?sources=SN18700&elements=wind_speed"

Note: The colon after the client ID indicates an empty password field.

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

OAuth2 authentication

Using OAuth2 is a two-step process: First generate an access token by passing the client ID and client secret to the auth/accessToken endpoint. Then use the access token to get data. The access token typically expires after 24 hours, after which a new one must be generated.

Examples using curl:

STEP 1, generate an access token:

      curl -d 'client_id=<client ID>&client_secret=<client secret>&grant_type=client_credentials' 'https://frost.met.no/auth/accessToken'
STEP 2, use the access token to get data:

      curl -H 'Authorization: Bearer <access token>' 'https://frost.met.no/observations/v0.jsonld?sources=...&elements=...&referencetime=...'
This example shows how the OAuth2 protocol can be used to access Frost from a Python script.


Some data available through Frost are confidential and require authorized access using OAuth2 (see above). Note: Accessing such data must be done using a special client ID and client secret provided by MET Norway, i.e. credentials generated with the self-service solution will not work.

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 the endpoint 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 timeSerieId:<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. In addition, when using repeating intervals, Frost allows the distance between the starting points of consecutive intervals to be specified explicitly (this is not part of ISO-8601). By default, this distance is the length of the interval, i.e. a zero gap between consecutive intervals.

NOTE: Intervals in Frost are open-ended: [t0,t1>, i.e. representing times later than or equal to t0 and earlier than t1. The only exception to this rule is when the two times are identical, in which case the interval is considered a single time point.

The basic forms available for expressing time in Frost are as follows:

So you can define a simple time range by writing: 2017-01-01/2017-02-01. The time will default to T0, so this example will get you all of January (from midnight on 01 January to midnight 01 February).

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

For further (more complicated) specification of time intervals the concepts below can be used:

Below is a visual representation of this time expression:

Where Fi = F + i * period

When using repetitions, express a gap between intervals by adding a period at the end. For example:

represents the two time intervals:



To repeat a single time point, specify an interval with two identical time points and make sure to add an explicit starting point distance:

represents the four time points:





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 10 and latitude 59 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.

Quality code

The data is run through a quality control system that can assign several different quality flags which mean different things. For further information see useinfo and controlinfo.

FROST tries to give the user a single value to represent the general quality of the observation. It is an aggregation of 2 of the flags given by the quality control system.

Below is the description of the two flags used:

useinfo[2] - quality level of the original value
  • 0 = original value found to be good
  • 1 = original value suspicious (likely correct)
  • 2 = original value suspicious (likely erroneous)
  • 3 = original value definitely erroneous
  • 9 = no quality information given
useinfo[3] - treatment of the original value
  • 0 = original value is kept unchanged
  • 1 = original value is manually or automatically corrected with a good result
  • 2 = original value is manually or automatically interpolated with a good result
  • 3 = original value is automatically corrected
  • 4 = original value is automatically interpolated
  • 5 = original value is manually created from accumulated values
  • 6 = original value is automatically created from accumulated values
  • 8 = original value is thrown out
  • 9 = quality information is not given

This is how FROST creates one value from them:

useinfo[2], useinfo[3] => FROST
  • anything, '1' => (1) // OK
  • anything, '2' => (1) // OK
  • anything, '3' => (6) // Very uncertain
  • anything, '4' => (6) // Very uncertain
  • anything, '5' => (1) // OK
  • anything, '6' => (1) // OK
  • '0', anything => (0) // OK
  • '9', anything => (2) // Uncertain
  • '1', '0' => (5) // Uncertain
  • '2', '0' => (5) // Uncertain
  • '3', '0' => (7) // Erroneous
  • '3', '8' => (7) // Erroneous
  • all other cases => None // Undefined


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: