The Yr Weather API: How to Use MET Norway Forecast Data Without Getting Blocked

Almost every app eventually needs a weather forecast. Maybe it is a booking tool that warns guests about snow, a delivery service that adjusts routes, or a simple dashboard that shows the next few days. For Nordic locations, one of the best free sources is the forecast data behind the Yr service, published as an open API by the Norwegian Meteorological Institute.

Using it well is mostly a matter of following a short list of rules. Break them and your requests start returning errors. Follow them and the service is fast, reliable and free. You can read more about the Yr API at MET Norway, and this guide walks through the parts that matter most when you build against it.

What the Yr API actually is

People search for the Yr API, the Yr no API or the API behind yr.no and expect a single product. In practice there are several services, each with its own purpose. The one most developers want is Locationforecast, which returns a forecast for a point you choose using latitude and longitude. Other services cover things like short-term precipitation nowcasts, and historical model data is available for the Nordic and Arctic regions.

The base address is on the api.met.no domain, and the full reference is in the official Locationforecast documentation. Read it once before you write any code, because several of the rules below are enforced by the server rather than suggested.

The endpoints you will use

• Compact: a JSON response with only the most commonly used parameters. This is the right default for most apps because the payload is smaller.
• Complete: a JSON response with all available values. Use it when you need something the compact version leaves out.
• Classic: a legacy XML format that matches the older version 1.9. New parameters are not added to it, so avoid it in new projects.
• Status: reports whether the forecast model is running normally.

The service also publishes a schema and an OpenAPI description, which is useful if you generate a client instead of writing requests by hand. The forecast covers the next nine days.

Parameters: latitude, longitude and altitude

Two parameters are mandatory: latitude and longitude, in decimal degrees. A third, altitude, is optional but recommended. It is given in whole meters and refers to the height of the ground surface, not to a height in the atmosphere.

If you leave altitude out, the service falls back on an internal terrain model that the documentation itself describes as rather coarse. In flat country that rarely matters. In hilly or mountainous areas it can give the wrong temperature. The FAQ is specific about what altitude does: it adjusts temperature according to elevation and nothing else, so it cannot be used to get wind speeds higher above the ground.

Rule 1: always send a real User-Agent

This is the rule that catches the most beginners. Requests with a missing or prohibited User-Agent receive a 403 Forbidden response. The documentation names default client strings from common libraries and platforms as examples of agents that are not accepted. The terms add that fake or random strings count as abuse.

The fix is simple. Identify your application with its name or domain, optionally a version number, and a way to contact you. If something goes wrong with your traffic, the operators then know whom to reach. If they cannot reach you, the terms say you can be blocked without warning, which is a bad surprise on a production site.

Rule 2: cache, and respect the headers

The terms are clear that you should not repeat a request until the time given in the Expires response header. Store responses locally, and use conditional requests so that unchanged data is not downloaded again. When you send an If-Modified-Since header, use the Last-Modified value from your previous response, not an arbitrary timestamp.

One more detail from the terms: do not send a HEAD request followed by a GET. On a cache miss that doubles the load on the server for no benefit.

How often does the forecast change?

Inside the Nordic area the forecast is updated every hour. Elsewhere it is updated every six hours. The FAQ asks you to wait at least half of the relevant interval before repeating a request. In practice that means polling Nordic locations no more often than every half hour, and other locations no more often than every three hours.

There is also an instruction that is easy to miss and easy to break: under no circumstance should you schedule requests to repeat at the top of the hour. If every application in the world fires at the stroke of XX:00, the servers see a spike, so spread your requests out. A scheduled job that runs at a random minute past the hour is better than one that runs on the hour.

If your app serves many users, put a small cache between them and the weather service, rather than letting every browser or phone call it directly. A shared backend is the natural place for that. If you are choosing one, our overview of what Supabase is and how modern app backends work is a good starting point.

Rule 3: truncate coordinates to four decimals

Latitude and longitude must be truncated to at most four decimals. For new products, requests with five or more decimals return 403 Forbidden. The FAQ explains the thinking: shorter coordinates make caching work better, because many users near each other end up asking for the same point.

This matters if you geocode place names. Geocoding services often return many decimals. Truncate the result before building the request, rather than passing it through as is. Four decimals is roughly accurate enough to identify a spot on a street, so you lose nothing that a weather forecast could use.

Rule 4: stay under the traffic limit

Traffic above 20 requests per second per application is allowed only with a prior agreement. The limit counts all installations and servers together, not each client. Most projects never come near it. If you expect to, talk to the operators first. The terms say that browser and mobile clients should use a caching proxy once their traffic grows significantly.

Excessive or non-compliant traffic is throttled with HTTP 429 responses instead of content. Deliberate breaches, attempts to evade the limit and impersonating other clients can lead to a permanent ban.

Rule 5: give credit under the licence

The data is open and licensed under CC BY 4.0. That means you may use it freely, including commercially, as long as you credit the source, link to the licence and say whether you made changes. Put the credit somewhere visible in your product, such as a footer or an about screen, rather than burying it. It takes a minute to add and avoids a legal question later.

A practical request checklist

1. Set a descriptive User-Agent with your app name and a contact address.
2. Truncate latitude and longitude to four decimals.
3. Pass altitude in whole meters if you know it, especially in hilly terrain.
4. Cache every response and honour the Expires header.
5. Send If-Modified-Since using the previous Last-Modified value.
6. Do not poll more often than half the update interval, and never on the hour.
7. Credit MET Norway and the licence in your product.

Common mistakes

Calling the API from the browser. It is tempting for a prototype, and it works. But every visitor then makes their own request, with the browser's default identification and no shared cache. Move the call to a backend as soon as the project has real users.

Forgetting to handle errors. A 403 or 429 should not crash your page. Show the last cached forecast with a note about its age, and retry later. This also protects you from short outages.

Ignoring the model's limits. The service is not suitable for forecasts above ground level, and aviation users are pointed to a different product. Short-term precipitation that needs updates every five minutes belongs in the nowcast service, not in the general forecast.

Treating a third-party API as always available. Any outside service can slow down or fail, and the same defensive habits apply whether it is a forecast or a payment provider. We cover those habits for payments in building Stripe webhooks you can trust in production.

Does it affect your page speed?

A weather widget that waits for a slow API call can hold up the rest of the page. Load the forecast after the main content, show a placeholder of the right size so the layout does not jump, and serve it from your own cache. These choices help the metrics we describe in Core Web Vitals in practice.

When Locationforecast is not the right tool

Locationforecast is a general-purpose forecast for a point on the map, and that covers most apps. It is not the answer to every weather question. If you need precipitation forecasts that refresh every five minutes, the nowcast service is built for that. If you need forecasts for aviation, the documentation points to a separate product. If you are doing analysis rather than showing a forecast, historical model data is available as NetCDF files for the Nordic and Arctic regions.

Choosing the right service early saves you from stretching one endpoint beyond what it was designed for. A rain alert that polls the general forecast every few minutes breaks the caching rules and still gives you worse data than the service made for the job. Match the question to the service first, and only then write the request code.

Summary

The Yr weather API is generous, free and reliable, and it asks little in return. Identify your application, truncate coordinates to four decimals, cache responses and respect the Expires header, spread your requests away from the top of the hour, stay under 20 requests per second, and credit the source under CC BY 4.0. Build those habits in from the start and you will rarely see an error, and your users will get a fast forecast whenever they open your app.