API guide
OpenWeatherMap Free Tier Limits 2026
OpenWeatherMap free tier limits in 2026: Free Weather API access, One Call 3.0/4.0 free-call thresholds, overage controls, and safer alternatives.

TL;DR
OpenWeatherMap still has a usable free path in 2026, but the answer depends on which product you call. The classic Free Weather API access path covers current weather, 3-hour forecast, air pollution, weather maps, and geocoding with 60 calls/minute and 1,000,000 calls/month on the public pricing page. The separate One Call products are subscription/pay-per-call products: OpenWeatherMap's One Call 3.0 docs describe a call-by-call subscription with 1,000 calls/day included, while the pricing page now markets One Call 4.0 as the newer timeline-based product with the first 1,000 API calls per day free.
If you need a no-card prototype, start with Free Weather API access or an alternative such as Open-Meteo. If you need One Call's minute/hour/day timeline, alerts, or unified historical/forecast shape, add a billing guard before the first production test.
Key takeaways
- Free Weather API access is still the no-card starting point. The pricing page lists 60 API calls/minute and 1,000,000 calls/month for the free weather access bundle.
- One Call is different from Free Weather API access. One Call 3.0 documentation says it uses a separate call-by-call subscription with 1,000 calls/day included; the pricing page now highlights One Call 4.0 with the same first-1,000-calls-per-day free framing.
- Do not mix endpoint paths.
/data/2.5/weatherand/data/2.5/forecastare not the same commercial surface as/data/3.0/onecallor the newer One Call 4.0 product. - Hard-cap paid products before load tests. Set account limits or billing alerts before cron jobs, mobile background refreshes, or CI smoke tests can create billable overage.
- Alternatives are better for some prototypes. Open-Meteo, the U.S. National Weather Service API, Weatherbit, Tomorrow.io, and Visual Crossing each solve a different free-weather problem.
Current OpenWeatherMap free-limit map
| Need | Product to check first | Current public free framing | Caveat |
|---|---|---|---|
| Current weather for a city or coordinate | Current Weather API in Free Weather API access | 60 calls/minute and 1,000,000 calls/month | Does not include the full One Call timeline. |
| 5-day / 3-hour forecast | Forecast API in Free Weather API access | Included in the same free access bundle | Hourly and daily long-range products may require paid plans. |
| Geocoding a place name to coordinates | Geocoding API in Free Weather API access | Included in the free access bundle | Use it to resolve coordinates before weather calls; do not assume it replaces a full Places API. |
| Unified current + minute/hour/day forecast | One Call API 3.0 / One Call 4.0 | First 1,000 calls/day free in official One Call copy | Requires subscription/pay-per-call posture; cap usage before launch. |
| Historical, accumulated, or larger commercial workloads | Paid Weather API plans or enterprise | Higher calls/minute and calls/month on paid tiers | Check license, SLA, attribution, and redistribution terms. |
Free Weather API access: the no-card path
For most prototypes, Free Weather API access is the safest OpenWeatherMap entry point. It covers the classic endpoints that many tutorials still use:
curl "https://api.openweathermap.org/data/2.5/weather?lat=40.7128&lon=-74.0060&units=metric&appid=$OPENWEATHER_API_KEY"
Use this path for:
- personal dashboards;
- prototypes that refresh weather a few times per hour;
- server-side weather widgets;
- geocoding a user's typed city before a forecast request;
- tests where a delayed or missing forecast is not catastrophic.
Even with a generous monthly call limit, add a cache. A weather value rarely needs to refresh on every page view. Cache by coordinate bucket, city, or postal code; expire current conditions every 5-15 minutes; and make mobile apps request through your backend instead of handing every installed client a direct polling loop.
One Call API 3.0 vs One Call 4.0
OpenWeatherMap's public pages now create a common source of confusion:
- The One Call API 3.0 documentation is still live and says access is available through a separate “One Call by Call” subscription with 1,000 calls/day included.
- The pricing page now markets One Call 4.0 as a timeline-based weather API for future and past data, also with the first 1,000 API calls per day free.
That does not mean you should blindly swap endpoint paths. It means you should decide which official product your app is actually using, then confirm the endpoint, fields, billing unit, and free threshold in the current docs.
A safe implementation checklist:
- Create the OpenWeatherMap API key in a server-side environment only.
- Confirm whether the route calls Free Weather API access or One Call.
- For One Call, set the daily call limit at or below the free threshold until usage is understood.
- Add a per-user or per-location cache so retries do not multiply cost.
- Alert on HTTP
401,429, and sudden daily-call spikes.
Cost model examples
| Scenario | Safer default | Why |
|---|---|---|
| Landing page weather badge | Free Weather API access + server cache | The data can be cached and the classic current-weather endpoint is enough. |
| Travel planner with hourly/daily forecast | One Call, capped during beta | The unified timeline is useful, but every user search can become a billable event. |
| Mobile app background refresh | Backend cache + strict rate limit | Direct client polling can multiply calls by installs and device wakeups. |
| Weather data enrichment batch | Paid plan or alternative provider test | Batch jobs need explicit throughput, retry, and billing controls. |
| U.S.-only civic/weather app | National Weather Service API first | Official, keyless U.S. data may be a better fit than a global commercial API. |
Alternatives to compare before committing
Open-Meteo
Open-Meteo is often the easiest no-key prototype because its public pricing page separates a free evaluation/prototyping tier from paid commercial API plans with monthly call budgets. It is a strong first test for weather widgets, prototypes, and open-source projects, especially when you do not need OpenWeatherMap-specific fields.
National Weather Service API
For U.S.-only apps, the National Weather Service API is official and keyless. It is not a global commercial weather platform, but it can be the right answer for civic tools, public-safety prototypes, and U.S.-only forecast surfaces.
Tomorrow.io, Weatherbit, and Visual Crossing
These providers are worth testing when the required fields drive the choice: air quality, pollen, fire weather, historical records, CSV export, or a more explicit commercial data license. Compare each provider's current free tier, attribution, caching, and redistribution rules before treating it as a drop-in OpenWeatherMap replacement.
Implementation pattern
const cacheKey = `weather:${Math.round(lat * 100) / 100}:${Math.round(lon * 100) / 100}`;
const cached = await cache.get(cacheKey);
if (cached) return cached;
const url = new URL("https://api.openweathermap.org/data/2.5/weather");
url.searchParams.set("lat", String(lat));
url.searchParams.set("lon", String(lon));
url.searchParams.set("units", "metric");
url.searchParams.set("appid", process.env.OPENWEATHER_API_KEY!);
const res = await fetch(url, { next: { revalidate: 600 } });
if (res.status === 429) throw new Error("OpenWeatherMap quota exceeded; serve stale cache or fallback");
if (!res.ok) throw new Error(`OpenWeatherMap error ${res.status}`);
const data = await res.json();
await cache.set(cacheKey, data, { ttl: 600 });
return data;
The important design choice is not the syntax. It is that the API key is server-side, the route caches by location, quota errors have a user-visible fallback, and production traffic cannot call a paid endpoint without limits.
Common mistakes
- Assuming “free tier” means One Call is cardless. Free Weather API access and One Call subscriptions are separate surfaces.
- Leaving the default paid daily limit unchanged. A staging cron or mobile retry loop can consume the free allowance quickly.
- Using browser-side API keys. Treat weather keys like any other backend credential; proxy through your server and cache responses.
- Ignoring license and redistribution rules. Weather data can have different rules for public display, caching, and commercial reuse.
- Copying old One Call 2.5 examples. Check the current 3.0/4.0 product docs before migration.
Source notes
Official sources checked on 2026-06-19:
- OpenWeatherMap pricing:
https://openweathermap.org/pricefor Free Weather API access, paid Weather API plans, and One Call 4.0 free-call language. - OpenWeatherMap One Call API 3.0 documentation:
https://openweathermap.org/api/one-call-3for the separate call-by-call subscription and included-call language. - Open-Meteo pricing:
https://open-meteo.com/en/pricingfor free evaluation/prototyping and commercial plan framing. - National Weather Service API documentation:
https://www.weather.gov/documentation/services-web-apifor U.S. official keyless weather API context.
Pricing, endpoint availability, and plan names change. Re-open the official pages before adding a cost calculator, public guarantee, or procurement recommendation.
Related APIScout guides
- Best Weather and Climate Data APIs 2026
- Tomorrow.io vs OpenWeatherMap API 2026
- Best Free APIs for Developers 2026
- Weather API directory
Browse weather and location APIs at APIScout.
The API Integration Checklist (Free PDF)
Step-by-step checklist: auth setup, rate limit handling, error codes, SDK evaluation, and pricing comparison for 50+ APIs. Used by 200+ developers.
Join 200+ developers. Unsubscribe in one click.