Open-Meteo

Implementation notes

When to use Open-Meteo

Open-Meteo is the default choice for any project that needs weather data without an API key, signup, or credit card. It serves ECMWF and GFS model output through a free, well-documented JSON API at api.open-meteo.com, with 10,000 calls/day for non-commercial use and a clearly priced €29/month commercial tier when you outgrow that. Pick it for prototypes, hobby projects, internal tools, and any production app where you can budget a small caching layer in front. Its free tier is unusually durable because the underlying numerical weather models are themselves publicly funded — Open-Meteo is essentially a caching and formatting layer over data that costs them nothing to acquire, which is why the tier has stayed stable since 2020 while most competitors have tightened theirs.

Common pitfalls

• The 10,000 calls/day budget averages to roughly one request every 8.6 seconds. A user-facing app that geocodes first (Nominatim: 1 req/sec) then fetches weather hits Nominatim's limit long before Open-Meteo's, so plan your bottleneck analysis accordingly.
• Open-Meteo requires latitude and longitude — it does not accept city names. Always pair it with a geocoding step.
• Forecast variables must be explicitly requested by name (e.g., `temperature_2m`, `wind_speed_10m`). Requesting an invalid variable name returns a 400 with a descriptive error, not a silent default.
• Historical data before 1940 is unavailable. The ERA5 reanalysis archive starts at 1940-01-01; requests outside this range return an error rather than partial data.
• The 'non-commercial use only' clause on the free tier is enforced softly but it is real. Internal company dashboards, paid SaaS features, and ad-supported apps all technically require the commercial plan. Open-Meteo will not block your IP for occasional commercial use, but a serious product should budget the €29/month tier rather than rely on the free endpoint.
• Response payloads are gzipped JSON and can grow surprisingly large when requesting many variables at hourly resolution over a 16-day forecast. A request with 12 hourly variables over the full forecast horizon returns ~150 KB compressed — fine for server-to-server, painful for mobile clients on slow networks. Request only the variables and time range you actually render.

Quick start (bash)

curl "https://api.open-meteo.com/v1/forecast?latitude=48.85&longitude=2.35&current=temperature_2m,wind_speed_10m&wind_speed_unit=mph"

From our monitoring

In our hourly monitoring, Open-Meteo consistently responds in under 300ms from European IPs and under 600ms from US-East. It is one of the most reliable APIs in the weather category — we have recorded fewer than two downtime events lasting more than 30 minutes in the past 90 days, and zero incidents lasting more than two hours. Status codes are clean: a malformed parameter returns a 400 with a machine-readable error body, never a misleading 200 with stale data. The team also publishes a transparent status page at status.open-meteo.com, which we cross-check our pings against — historical agreement is over 99%.

Production integration patterns

Geocode-then-fetch (the standard pattern)

Open-Meteo only accepts latitude/longitude, so every user-facing weather feature needs a geocoding step first. The free option is Nominatim (OpenStreetMap), which is hard-capped at 1 request per second per IP — significantly stricter than Open-Meteo's own budget. In practice this means your effective throughput is bounded by geocoding, not weather. Cache geocoding results aggressively: city-name → lat/lng is stable enough that a 30-day cache is safe. If you only have a handful of cities, hardcode the coordinates once and skip geocoding entirely. Open-Meteo also offers its own free geocoding endpoint at geocoding-api.open-meteo.com which is faster and unrate-limited in practice, but covers fewer obscure place names than Nominatim.

Edge-cache to multiply the free tier

Open-Meteo responses for the same lat/lng change at most once per hour — the underlying numerical weather models update on an hourly cadence. On Cloudflare Workers, deploying a thin proxy that rounds lat/lng to one decimal (~11 km grid) and caches responses for one hour turns a 10,000 calls/day budget into effectively unlimited: your origin sees a few hundred hits per day, the rest are served from the cache layer. This is how we handle the 81-API monitoring fleet that powers this site, and how most production users we have seen run the free tier well past its nominal limits. Cache key: hash(lat_rounded, lng_rounded, variables_sorted, units). TTL: 3600 seconds. Stale-while-revalidate is safe.

Bulk historical via the archive endpoint

Historical data (ERA5 reanalysis, 1940-present) lives on a separate base URL: archive-api.open-meteo.com/v1/archive. The rate limits are stricter than the forecast endpoint, and requests covering more than a year at hourly resolution will time out before the server finishes the SQL pull. For multi-year ingestion, split the date range into yearly chunks, request only the variables you actually need (each extra variable roughly linear in response size), and parallelise modestly — three to four concurrent requests is the practical ceiling before you start seeing 429 responses. For ML training workloads larger than a few cities × ten years, contact them about the commercial bulk tier rather than scraping the API.

Compared to the closest paid alternatives

vs OpenWeather — Free: 1k/day, 60/min · Startup: $40/mo for 100k/day

Choose Open-Meteo unless you specifically need OpenWeather's city-name lookup (it accepts 'London,GB' directly) or one of its proprietary derived layers like UV index history. OpenWeather's free tier is 1,000 calls/day — 10× tighter than Open-Meteo — and requires an API key whose key-rotation flow is awkward. The paid plans start at $40/month for 100k calls/day; Open-Meteo's commercial plan offers similar volume at €29/month. OpenWeather wins on developer brand recognition and library ecosystem; Open-Meteo wins on every quantitative metric we measure.

vs WeatherAPI.com — Free: 1M/mo · Pro: $4/mo with history + marine

WeatherAPI's free tier is genuinely competitive: 1 million calls per month works out to ~33k per day, more than 3× Open-Meteo's daily budget. It also has built-in location autocomplete, marine data, astronomy endpoints, and air quality in one bundled response. The catch is feature gating — historical data and 14-day forecasts move to the $4/month tier. For a no-key prototype Open-Meteo wins; for a commercial app needing autocomplete and weather alerts out of the box, WeatherAPI's $4/month tier is hard to beat. In our monitoring WeatherAPI has been slightly slower (median 450ms vs Open-Meteo's 280ms) but well within acceptable range.

vs Visual Crossing — Free: 1k records/day · Standard: $0.001/record

Visual Crossing is the strongest paid choice when historical data is the primary use case. It offers 50+ years of cleaned and gap-filled records (Open-Meteo's archive goes to 1940, technically deeper, but Visual Crossing's series are smoother and load faster for analytical queries). The free tier is 1,000 records per day; paid is metered at $0.001 per record with no monthly minimum. If you need bulk historical pulls for analytics, climate modeling, or ML training, Visual Crossing's commercial terms are simpler and the per-record price is predictable. For real-time forecasts only, Open-Meteo remains the better default.

Embed this badge

Add a live status badge to your README, docs, or website.

Markdown

[![Open-Meteo Status](https://freeapi-builder.a10ayassine.workers.dev/badge/open-meteo.svg)](https://freeapi.watch/open-meteo)

HTML

<a href="https://freeapi.watch/open-meteo"><img src="https://freeapi-builder.a10ayassine.workers.dev/badge/open-meteo.svg" alt="Open-Meteo Status"/></a>