Choosing a weather API is less about finding the provider with the biggest feature list and more about matching its coverage, forecast data, usage terms, and price to your app. A free developer tier may exclude commercial use, restrict forecast endpoints, or become expensive when every visitor triggers a request.
This guide compares maintained options for small apps and services. Provider plans change, so use the linked documentation and pricing pages to confirm current limits before you ship.
Weather APIs to consider
| API | A good fit for | Important limits to check |
|---|---|---|
| National Weather Service API | U.S.-focused forecasts, observations, and alerts | U.S. coverage only. No fee or API key is required, but send an identifying User-Agent, cache responses, and respect the service's unpublished rate limits. |
| Open-Meteo | Prototypes and non-commercial apps that need global forecast data without an API key | Its free API is for non-commercial use, is limited to 10,000 calls per day, and has no uptime guarantee. The data uses CC BY 4.0 attribution. Commercial use requires a subscription and customer endpoint; see the current usage terms and pricing. |
| OpenWeather (API reference) | Apps that need a broader set of current, forecast, and historical weather products | Each product has its own access and billing terms. The current One Call 4.0 pricing lists the first 1,000 calls per day as free, then charges GBP 0.0012 per additional call. Check the live price and endpoint terms for the exact product you plan to use. |
| WeatherAPI.com | A single API for current conditions, forecasts, and related weather data | The published free plan currently lists 100,000 calls per month. Forecast range, history, commercial-use rights, and other features vary by plan; check the pricing matrix rather than assuming every endpoint is included. |
| Weatherbit | Current conditions and daily forecasts, with a clear path to higher-volume plans | Its free plan currently lists current weather and 7-day daily forecasts at 50 requests per day for non-commercial use. Commercial use requires an eligible paid plan; confirm current terms on the pricing page. |
| Tomorrow.io (API reference) | Apps evaluating a hosted forecast API with additional weather data products | ClimaCell now redirects to Tomorrow.io. Use the current API reference and confirm the available products, free-tier limits, and commercial terms with the provider; do not rely on old ClimaCell quota or pricing claims. |
OpenWeather, WeatherAPI.com, Weatherbit, and Tomorrow.io require an account or API key for their hosted services. Keep keys on a server you control when the provider's terms allow it; do not embed a private key in JavaScript shipped to every browser or commit it to a repository.
Other established providers include AccuWeather's developer portal and World Weather Online's weather API. Compare their current packages, location coverage, response fields, and redistribution rights before choosing them; old plan descriptions are not a substitute for current terms.
The Weatherstack pricing page currently lists a free plan with 100 calls per month for non-commercial use and real-time weather. That is a small sandbox, not the old 1,000-calls-per-month claim or a general-purpose free forecast plan. Its current API documentation describes the available endpoints.
Do not reuse old Weather Underground API quotas or pricing from archived roundups. Its former API URL now redirects to an account login rather than current developer documentation.
Make a small test request
For a non-commercial prototype, Open-Meteo's public forecast endpoint can be called without an API key. This request asks for current conditions and daily values for New York:
GET https://api.open-meteo.com/v1/forecast?latitude=40.7128&longitude=-74.0060¤t=temperature_2m,relative_humidity_2m,precipitation,weather_code&daily=temperature_2m_max,temperature_2m_min,precipitation_probability_max&timezone=America%2FNew_York
The response separates current values and daily forecasts into current and daily objects. Choose the variables and timezone your interface actually uses, and follow Open-Meteo's attribution and usage terms. For a paid app or business service, use a plan that explicitly permits the intended commercial use.
A practical selection checklist
- Test the locations that matter. Compare a few target coordinates, including rural or coastal areas if your users live there. Coverage, forecast horizon, and update frequency can differ by product and location.
- Check the data contract. Confirm commercial use, redistribution in an app, required attribution, caching, historical-data retention, and whether a free plan covers the forecast fields you need.
- Estimate requests before launch. A page view can create several API calls. Cache responses on a schedule suited to the provider's update cadence, and avoid requesting the same location separately for every visitor.
- Protect keys and locations. Keep private keys out of public client bundles. Send only the location precision your feature needs, and explain location use to people using the app.
- Plan for failure. Handle timeouts, authentication errors,
429responses, and provider outages. Respect retry guidance, back off rather than retrying in a tight loop, and label cached forecasts with their retrieval time instead of presenting stale data as live.
For a U.S.-only project, start by checking whether the National Weather Service API covers the locations and data you need. For a non-commercial prototype, compare Open-Meteo's terms with your requirements. For a commercial product, shortlist providers only after confirming forecast coverage, usage rights, and the full cost at your expected request volume.
If you are designing a weather app, these free weather icon sets can help with its interface. Treat icons and API values separately: map each provider's documented condition codes to your chosen icon set rather than assuming different APIs use the same codes.