What this category does
A weather API or data feed delivers forecasts, observations or both to software. Your application sends a location and a time range, and the provider returns values such as temperature, precipitation and wind in a machine-readable format. Some providers sell a general-purpose forecast for any point on earth. Others specialize in a region, a parameter or a delivery style, such as bulk files for a data warehouse.
Most of what separates one provider from another is hidden behind the same endpoint shape. Two APIs can return the same field names while using different underlying models, different update schedules and different rules for filling gaps. That is why a weather API is worth testing against your own use rather than judging by its documentation page.
Cost is the last thing to settle, not the first. A cheap plan that fails on a busy day, or that forbids storing the data you need, costs more than a plan priced for your real use.
How buyers evaluate
Buyers usually start with a short list of three or four providers and run a bake-off. They pull forecasts for the locations that matter to them, compare those against observations from a source they trust, and look at the misses that would have cost them something. A week is enough to catch outages and rate-limit surprises, but accuracy needs a longer window that includes the weather you care about, so a trial of a month or more is common for serious evaluations.
An RFP for a weather feed tends to cover coverage and parameters, update frequency, historical depth, uptime commitments, licensing terms and price at your expected call volume. Developers weigh documentation quality and how quickly they get a first successful response. Business buyers weigh support, contract terms and whether the provider will still be there in three years.
Try the free tier or trial with your real access pattern, not a single request. Many pricing surprises appear only when a job requests thousands of locations an hour.
Questions to ask a vendor
- Which models or sources produce the forecast for my region, and is that disclosed?
- How often is the forecast refreshed, and how old can a response be when I receive it?
- How far back does the historical data go, and is it the same data stream I will use live?
- What happens to a request when you are over a limit: an error, a throttle or an overage bill?
- What uptime do you commit to in the contract, and what is the remedy when you miss it?
- May I store the data, redistribute it or show it to my own customers?
- How much notice do you give before you change or retire a model version or an endpoint?
How to read the capability facts
Each provider profile lists regions, forecast types, parameters, product types and delivery methods. Treat these as a first filter. A provider that lists a parameter can still deliver it at a quality that does not suit you, and one that lists a region as covered may serve it with a coarser model than another region. The pricing model and free tier fields tell you whether you can test before you buy.
A Verified badge means a provider has been through an independent evaluation. A missing fact is not a negative signal. It may only mean the profile has not been completed, so ask the vendor directly.
Where to go next
Start from a short list and test it against your own locations and your own failure cases.
Browse the Weather APIs & Data Feeds providers, filter them by region, parameter and pricing, or compare several side by side. The full list of categories is the place to start if your need spans more than one.