Authentication overview

Meteorologisk Institutt, through its developer portal at yr.no, provides access to weather data primarily for non-commercial and limited commercial use. Unlike many other API providers that rely on explicit API keys or OAuth tokens for all access tiers, Meteorologisk Institutt's approach for its free and standard usage tiers emphasizes user agent identification. This method requires clients to send a descriptive User-Agent header with each request, allowing the service to identify the application or user making the request. This system is designed to facilitate broad access while enabling Meteorologisk Institutt to monitor usage patterns and enforce fair use policies, including rate limiting.

For commercial applications beyond the defined free-tier limits, or for integrations requiring higher request volumes, Meteorologisk Institutt requires direct contact for specific licensing arrangements. These arrangements may involve different authentication mechanisms, which are provisioned and detailed on a case-by-case basis. Developers are advised to consult the official documentation for the most current and specific requirements related to their intended use case.

Supported authentication methods

The Meteorologisk Institutt API primarily utilizes a client-side identification method for most users, with specific arrangements for commercial partners. The table below outlines the core approaches:

Method When to Use Security Level
User Agent Identification Non-commercial use, limited commercial use (default) Low (identifies client, not user)
Commercial Licensing (negotiated) High-volume commercial applications Variable (depends on negotiated terms, may include API keys or other credentials)

User Agent Identification

The fundamental method for accessing Meteorologisk Institutt's APIs without explicit API keys is through the consistent and accurate use of the User-Agent HTTP header. This header should provide a clear and unique identifier for your application, including contact information. For instance, a recommended format is YourAppName/1.0 ([email protected]). This enables Meteorologisk Institutt to contact developers regarding usage, changes, or issues. While not a traditional authentication mechanism in terms of verifying user identity, it serves as a crucial identification and communication channel for the service provider.

Commercial Licensing and Custom Credentials

For usage that exceeds the free and limited commercial terms, Meteorologisk Institutt stipulates that developers must contact them directly to discuss commercial licensing. In such scenarios, the authentication method may evolve. This could involve the issuance of unique API keys, client IDs, or other credential types typical in commercial API access. These custom credentials would then be used to authenticate requests, granting access to higher rate limits or specialized datasets not available through the public, user-agent identified access. The specific implementation details, including where to include these credentials (e.g., in a header, query parameter), would be provided upon successful licensing negotiation.

Getting your credentials

The process for obtaining credentials varies based on your intended use of the Meteorologisk Institutt APIs:

For Non-Commercial and Limited Commercial Use

  1. No formal registration or API key required: For standard, non-commercial, and limited commercial use, you do not need to register for an API key or account.
  2. Implement a descriptive User-Agent: Your primary 'credential' is a well-formed User-Agent header in your HTTP requests. This header should identify your application and provide a contact email. For example: MyWeatherApp/1.0 ([email protected]). This allows Meteorologisk Institutt to understand the source of requests and manage traffic appropriately. Ensure this information is unique and up-to-date.
  3. Adhere to attribution requirements: All uses of Meteorologisk Institutt data require clear attribution to 'Meteorologisk institutt and NRK' and a link to yr.no.

For High-Volume or Unrestricted Commercial Use

  1. Contact Meteorologisk Institutt directly: If your project requires usage beyond the free or limited commercial terms, you must initiate contact with Meteorologisk Institutt to discuss a commercial license. The official developer portal is the starting point for this outreach.
  2. Negotiate terms: During this process, you will discuss your specific needs, projected usage volume, and the nature of your commercial application.
  3. Receive custom credentials: If a commercial agreement is reached, Meteorologisk Institutt will provision any necessary API keys, client IDs, or other authentication tokens. These will be accompanied by specific instructions on how to use them in your API requests, which may differ from the default user agent method.
  4. Review specific documentation: Any custom credentials will likely come with dedicated documentation detailing their usage, rate limits, and security considerations unique to your commercial agreement.

Authenticated request example

Since the primary authentication method for most users of the Meteorologisk Institutt API relies on the User-Agent header, an example request demonstrates how to properly include this header. For commercial users with specific credentials, the method of inclusion (e.g., query parameter, different header) would be provided with their license.

Example using curl (User Agent Identification)

This example retrieves a location forecast for Oslo, Norway, using the recommended User-Agent format:

curl -H "User-Agent: MyWeatherApp/1.0 ([email protected])" \
     "https://api.met.no/weatherapi/locationforecast/2.0/compact?lat=59.9112&lon=10.7478"

In this example:

  • -H "User-Agent: MyWeatherApp/1.0 ([email protected])": This sets the HTTP User-Agent header. Replace MyWeatherApp/1.0 with your application's name and version, and [email protected] with a valid email address for contact.
  • "https://api.met.no/weatherapi/locationforecast/2.0/compact?lat=59.9112&lon=10.7478": This is the endpoint for the Locationforecast 2.0 API, requesting data for a specific latitude and longitude.

Example in Python (User Agent Identification)

Here's how you might make a similar request using the requests library in Python:

import requests

url = "https://api.met.no/weatherapi/locationforecast/2.0/compact?lat=59.9112&lon=10.7478"
headers = {
    "User-Agent": "PythonWeatherScript/1.0 ([email protected])"
}

response = requests.get(url, headers=headers)

if response.status_code == 200:
    print(response.json())
else:
    print(f"Error: {response.status_code} - {response.text}")

Security best practices

When integrating with Meteorologisk Institutt's APIs, especially given its unique authentication model, consider the following security best practices:

  1. Protect your User-Agent information: While the User-Agent is not a secret credential in the traditional sense, treating it as such is prudent. Do not hardcode sensitive contact information directly into publicly distributable client-side code. If your application is client-side, consider proxying requests through a backend to manage the User-Agent header securely.
  2. Keep contact information up-to-date: The email address provided in your User-Agent header is Meteorologisk Institutt's primary method of contacting you regarding API changes, policy updates, or potential abuse. Ensure it is actively monitored.
  3. Respect rate limits: Meteorologisk Institutt enforces rate limits to ensure fair use and service stability. Implement robust error handling (e.g., catching 429 Too Many Requests HTTP status codes) and exponential backoff strategies to prevent your application from being temporarily blocked. Over-requesting can be interpreted as a denial-of-service attempt, even if unintentional.
  4. Use HTTPS exclusively: All communication with Meteorologisk Institutt's APIs should occur over HTTPS. This encrypts data in transit, protecting both your requests and the received weather data from eavesdropping and tampering. Most modern HTTP client libraries default to HTTPS, but always verify. The IETF's RFC 7230 on HTTP/1.1 Message Syntax and Routing specifies the use of TLS for secure communication.
  5. Validate and sanitize input: If your application constructs API requests based on user input (e.g., latitude/longitude values), always validate and sanitize this input to prevent injection attacks or malformed requests that could lead to unexpected behavior or security vulnerabilities.
  6. Implement robust error handling: Your application should gracefully handle various API responses, including errors. This includes network errors, HTTP status codes indicating issues (e.g., 400 Bad Request, 500 Internal Server Error), and specific error messages from the API. Proper error handling can prevent application crashes and provide a better user experience.
  7. Regularly review terms of use: Meteorologisk Institutt may update its terms and conditions, including authentication requirements and usage policies. Periodically review the official documentation to ensure ongoing compliance.
  8. Securely store commercial credentials: If you obtain specific API keys or client secrets through a commercial license, treat them as sensitive credentials. Store them securely (e.g., environment variables, secret management services) and never hardcode them directly into your source code or expose them in client-side applications.