How to Scrape Open-Meteo Weather Data (Free, No API Key)

Most weather APIs make bulk extraction annoying: you register for a key, get metered on a stingy free tier, and hit a rate limit halfway through a multi-city pull. Open-Meteo is the exception — a free, open-source weather API with no registration and no key, trusted by major weather apps and serving over a billion API calls a day from its own infrastructure. The friction that’s left is shape, not access: the API returns time-series data as parallel arrays, and you want rows. This guide covers how Open-Meteo’s endpoints work and how to turn them into a clean dataset.

What’s worth extracting

The scraper flattens Open-Meteo’s time-series arrays into one row per time point per location. About 16 fields, grouped by role:

• Location — location (the name you provided), latitude, longitude, country, and timezone (IANA, e.g. Europe/London).
• Row type — dataType, one of hourly, daily, or geocoding, telling you which fields on the row are meaningful.
• Time — time, an ISO datetime (2025-07-08T14:00) for hourly rows or a date (2025-07-08) for daily rows.
• Hourly measurements — temperature (air temp at 2 m in °C), precipitation (mm), windSpeed (at 10 m in km/h), and humidity (relative humidity at 2 m in %).
• Daily summaries — temperatureMax and temperatureMin (°C), populated only on daily rows.
• Conditions — weatherCode (WMO interpretation code) and weatherDescription (plain-English condition like Moderate rain or Clear sky).
• Geocoding extras — name (official city name), population, and admin1 (state/region), populated only on geocoding rows.

The dataType field is how you read the rest: hourly rows carry temperature but leave temperatureMax/temperatureMin empty; daily rows do the reverse; geocoding rows only fill name, population, and admin1. Empty strings mean “not applicable to this row type,” not missing data.

How Open-Meteo’s endpoints work

The scraper wraps three official Open-Meteo endpoints and switches between them by mode:

forecast:   https://api.open-meteo.com/v1/forecast
historical: https://archive-api.open-meteo.com/v1/archive
geocoding:  https://geocoding-api.open-meteo.com/v1/search

You supply city names or lat,lon pairs. If you give it a city name, the actor calls the geocoding service first to resolve it to coordinates, then hits the forecast or archive endpoint and flattens the returned arrays into rows. The three modes map to what you’re doing:

• forecast — up to 16 days ahead. Each location yields up to 16 days × 24 hours = 384 hourly rows covering temperature, precipitation, wind, humidity, and WMO code.
• historical — the ERA5 reanalysis archive, back to January 1, 1940 for most locations. A 30-day pull for 10 cities is 7,200 rows; a full year for one location is 365 × 24 = 8,760 hourly rows.
• geocoding — resolve a name to coordinates, returning up to 10 candidate cities per query with population and region.

The most common run is a forecast by city name:

{
  "mode": "forecast",
  "locations": ["London", "Tokyo", "New York", "Berlin"],
  "hourly": true,
  "daily": false,
  "forecastDays": 7
}

Historical mode needs a date range and accepts a mix of names and coordinates:

{
  "mode": "historical",
  "locations": ["Berlin", "Paris", "48.8566,2.3522"],
  "startDate": "2024-01-01",
  "endDate": "2024-01-31",
  "hourly": true,
  "daily": true
}

Setting both hourly and daily to true gives you the granular series and clean daily summaries in the same run.

▶ Run the Open-Meteo Weather Scraper on Apify — feed cities or coordinates, get hourly and daily temperature, precipitation, wind and humidity for forecasts or any historical range. No API key, no login. Export to CSV, JSON or Excel.

The access reality

This is the rare data source where “the access reality” is genuinely relaxed — and that shapes how you run it.

• No key, no proxy needed. Open-Meteo does not block datacenter IPs and has no rate limit for reasonable usage. You can disable proxy entirely to save cost — the proxy config exists but isn’t required.
• The real limit is volume, not access. Because there’s no throttling, the constraint becomes row count and runtime. The 16-day forecast horizon is a hard ceiling (forecastDays caps at 16); for longer planning you re-run on a schedule. Historical long ranges multiply fast — a one-year hourly pull is 8,760 rows per location, so scale memory only when you’re querying dozens of locations at once.
• Locations process sequentially. There’s no hard cap on how many you feed, but they’re handled one after another and pushed incrementally. For 100 cities × 7-day hourly forecast, expect roughly 16,800 rows and a 2–5 minute run at 512 MB.

On accuracy: Open-Meteo blends multiple meteorological models (ECMWF, GFS, DWD) for forecasts comparable to national weather services, and its historical data is ERA5 reanalysis — the standard reference in climate science. Model data refreshes every 1–6 hours depending on the underlying model, so daily forecast runs are plenty for most uses.

Example output

An hourly forecast row and a daily summary row for the same location show how dataType splits the fields:

{
  "location": "Tokyo",
  "latitude": "35.6895",
  "longitude": "139.6917",
  "country": "Japan",
  "timezone": "Asia/Tokyo",
  "dataType": "hourly",
  "time": "2025-07-08T09:00",
  "temperature": "31.2",
  "precipitation": "0.1",
  "windSpeed": "12.5",
  "humidity": "72",
  "weatherCode": "3",
  "weatherDescription": "Overcast",
  "admin1": "Tokyo"
}

{
  "location": "Tokyo",
  "dataType": "daily",
  "time": "2025-07-08",
  "temperatureMax": "33.4",
  "temperatureMin": "26.1",
  "precipitation": "2.3",
  "admin1": "Tokyo"
}

The hourly row fills temperature, windSpeed, and humidity; the daily row fills temperatureMax/temperatureMin and leaves the hourly-only fields empty. That’s by design.

Typical use cases

• Retail demand forecasting — pull 16-day hourly forecasts for store locations to predict how weather drives foot traffic and product mix.
• Energy consumption modeling — extract temperature and humidity series for a portfolio of buildings to train HVAC load models.
• Historical climate studies — download decades of daily max/min temperatures for hundreds of cities for academic or journalistic climate research (ERA5 back to 1940).
• Logistics route weather — get hourly wind and precipitation for waypoints along a transport corridor to flag risk windows.
• Event planning — check 16-day forecasts for candidate venues and export to Google Sheets for side-by-side comparison.
• ML feature engineering — join weather series onto sales, ridership, or sensor data as predictive features.

Cost / effort math

You could call these endpoints directly — they’re free and documented, so the API access costs nothing. What you’d be building and maintaining is the plumbing: geocoding city names to coordinates (and handling the ambiguous ones), fanning out across three endpoints, flattening the parallel time arrays into aligned rows, and paging through large historical ranges without running out of memory. It’s not hard, but it’s real code to own.

The managed actor runs pay-per-result — a 1,000-row forecast run costs a fraction of a cent, and because no proxy is required, there’s no bandwidth bill underneath it. For a daily 7-day forecast across a handful of cities, you’re spending pennies a month with the geocoding, endpoint routing, and array-flattening already handled.

Common pitfalls

• Ambiguous city names resolve to the most populous match. “Springfield” hits multiple US cities; the actor takes the top geocoding result by population rank. If you need a specific one, run geocoding mode first to inspect the match, then pass lat,lon (e.g. "39.7994,-89.6502" for Springfield, IL) instead of the name.
• Empty fields are row-type markers, not gaps. temperatureMax empty on an hourly row, or temperature empty on a daily row, is expected. Filter on dataType before reading a field.
• Values come back as strings. temperature, windSpeed, and the rest arrive as strings; cast them to numbers before arithmetic.
• Units are fixed. Temperature is °C, wind is km/h at 10 m, precipitation is mm, humidity is % at 2 m. If your pipeline expects Fahrenheit or mph, convert downstream.
• Historical is reanalysis, not observations. ERA5 is a modelled reconstruction — excellent and standard for climate work, but not identical to a specific station’s raw readings. Know which you need.
• 16 days is the forecast ceiling. For longer horizons there’s no single call — schedule the actor to re-pull as the window rolls forward.
• WMO codes need translation for humans. weatherCode is a numeric WMO code (0 = clear, 45–48 = fog, 51–67 = drizzle/rain, 71–77 = snow, 95–99 = thunderstorms); weatherDescription already gives you the plain-English version, so use that for display.

Wrapping up

Open-Meteo removes the usual weather-API friction — no key, no quota, no proxy, global coverage, and history back to 1940 — which flips the engineering problem from access to shape: geocoding names, routing across three endpoints, and flattening time-series arrays into aligned rows. Set dataType-aware parsing, cast the string values, and mind the 16-day forecast ceiling. If you’d rather skip the plumbing, the managed actor handles all three modes in one place.

▶ Open the Open-Meteo Weather Scraper on Apify — one run turns a list of cities into hundreds of forecast or historical rows: temperature, precipitation, wind, humidity, and WMO conditions. No API key, no login, export to CSV / JSON / Excel. Start on Apify’s free monthly credit.