Norway

MET Norway Nowcast

How MET Norway's Nowcast 2.0 reports radar coverage explicitly through a named field and an HTTP status, and why a blocked User-Agent looks like an outage.

At a glance

Product: Nowcast 2.0, radar precipitation for the next 2 hours
Format: JSON, GET nowcast/2.0/complete
Coverage: Norway and the Nordics; reaches into Denmark and Finland, partially
Access: No API key; a meaningful User-Agent header is mandatory
Blocked clients: Generic User-Agents such as okhttp, Dalvik and Java
Units: precipitation_rate in mm/h directly, no conversion

Licence: Norwegian Licence for Open Government Data (NLOD) 2.0, and CC BY 4.0 International
Required attribution: Credit The Norwegian Meteorological Institute, shortened to MET Norway, as the source. "Data from MET Norway" is an accepted form; a link back is encouraged.

How it signals an absence

Three different facts, and only one of them is a zero.

On the wire these three collapse onto one field. A measurement is radarStatus: "available"; no coverage is radarStatus: "out-of-coverage"; and no measurement, a failed or empty attempt, is radarStatus: "temporarily-unavailable". That field describes the outcome of the whole routing pass, not the one network this page is about: NowcastRouter walks the registered national adapters in order and returns as soon as one reports a measurement, so a point this adapter reports as out-of-coverage can still come back available if a different adapter further down the order answers instead, and can come back temporarily-unavailable rather than out-of-coverage if any other adapter in the pass failed instead of declining. radarCoverage sits beside it: "ok" appears only together with available, and "model-fallback", meaning Open-Meteo's model nowcast answered instead, can appear with either out-of-coverage or temporarily-unavailable.

Signal	Upstream meaning	We report	Why
`HTTP 422`	Outside the geographic area	`out-of-coverage`	The point sits entirely outside the product's domain. Verified live for Berlin. Permanent.
`radar_coverage: "no coverage"`	No coverage	`out-of-coverage`	Inside the outer domain but no radar reaches this point. Verified live for Aarhus, which sits well inside the 422 boundary.
`radar_coverage: "temporarily unavailable"`	Temporarily unavailable	`unavailable`	A radar plausibly covers the point but the feed has no answer right now. Worth asking again shortly.
`radar_coverage: "ok", empty timeseries`	Coverage confirmed, no timestep returned	`unavailable`	A gap in the feed under a point the endpoint itself says is covered, not evidence the point is uncovered.
`radar_coverage: "ok", timeseries present`	Coverage confirmed, reading present	`measurement`	A radar measured this point. The rate may legitimately be 0 mm/h.

What the product is

MET Norway's Nowcast 2.0 is a radar precipitation product covering the next two hours, served as JSON from nowcast/2.0/complete. It is the only one of the seven national networks behind this API that carries coverage as a named field on the response itself, rather than a status code or a raw sentinel value a reader has to look up elsewhere: the response carries a radar_coverageproperty that says outright, in words, whether a radar reaches the point. MRMS also has a named coverage state, -3, published as "No Coverage" in NOAA's own table, but that name lives in NOAA's documentation, not in the response MRMS actually returns.

The endpoint requires a meaningful User-Agent header. Generic strings such as okhttp, Dalvik and Java are blocked outright, so a request identifying itself as DroneInfo/0.4 [email protected], or similar, is not optional politeness. It is the difference between a response and a block.

Two layers of absence, not one

A request to this endpoint can decline to answer in two different ways, at two different layers, and neither of them is a rate. The outer layer is the HTTP response itself: a point entirely outside the product's domain gets back 422. Verified live 2026-07-30, a request for Berlin answers this way. That is a permanent fact about the point, not a hiccup to retry.

The inner layer only appears once the request is inside that outer domain, and it is the radar_coverage field on a 200 response. Its value is one of "ok", "no coverage", or "temporarily unavailable". The middle one is the interesting case: the same live check found Copenhagen, Helsinki and Stockholm answering ok, while Aarhus, well inside the endpoint's outer domain, answers no coverage. Coverage reaches into Denmark and Finland, and only partly. It is not a bounding box, it is wherever an actual radar happens to reach.

One more gap sits underneath even a coverage-confirmed point: the timeseries returned alongside radar_coverage: "ok" can itself be empty. That is a data gap in a place a radar is known to cover, not a confirmation that no radar covers it, so it is reported the same way as "temporarily unavailable" rather than folded into the coverage question above it.

Reading one point yourself

GET nowcast/2.0/completebash

curl -s \
  -H "User-Agent: DroneInfo/0.4 [email protected]" \
  "https://api.met.no/weatherapi/nowcast/2.0/complete?lat=59.9139&lon=10.7522" \
  | jq '.properties.meta.radar_coverage, .properties.timeseries[0].data.instant.details.precipitation_rate'

A generic User-Agent (okhttp, Dalvik, Java, or no header at all) is blocked before radar_coverage ever enters the picture; a blocked request and an out-of-coverage point look nothing alike, but a lazily-set header can make an entire integration look like a coverage problem it does not have.
422 means the request itself was rejected as out of the product's domain. A 200 with radar_coverage other than "ok" means the request was accepted but the point, or the moment, has no reading.

Or call the API instead

The same reading, normalised, with the source that answered named in the response. No key and no signup for the demo endpoint.

curlbash

curl "https://api.droneinfo.app/v1/demo/weather/point?lat=59.9139&lon=10.7522"

Run it for Oslo in the browser