Free Weather API Without Key: Tested Endpoints
Key takeaways
- Open-Meteo, wttr.in, and api.weather.gov all return live weather data to an unauthenticated plain GET with no signup or token.
- Open-Meteo is the strongest keyless option, offering current conditions, hourly data out to 16 days, and daily aggregates in one call.
- Keyless endpoints rate-limit by IP, so Open-Meteo's documented ceiling of 10,000 requests per day and 600 per minute is shared with everyone behind your NAT.
- Open-Meteo requires CC-BY attribution even for commercial use, so keyless access is not license-free access.
- Once weather gates a payment, shipment, or agent spend decision, graduate to a keyed or pay-per-call endpoint with a contract and SLA.
Several weather APIs return live data with no signup and no key: Open-Meteo, wttr.in, and the NWS api.weather.gov endpoints all respond to a plain GET from curl or an agent tool call. This guide tests each one at the endpoint level, then shows when a keyed or pay-per-call API in USDC on Base is worth the switch.
Which weather APIs work with no API key at all?
The shortlist we tested
Open-Meteo is the strongest keyless option: global forecasts, hourly and daily fields, no signup, no header, no token. Its docs cover the request format, response fields, and non-commercial rate limits in one place (Open-Meteo API docs). MET Norway's Locationforecast is the other reliable keyless endpoint, requiring only a User-Agent identifying your client. Both return JSON that an agent can parse directly into a tools/list-style response without wrapper code.
What 'no key' actually means at the HTTP level
No key means the request is a plain GET with query parameters and nothing else: no Authorization header, no apikey query param, no account provisioned server-side. The 402 challenge flow you know from x402 pay-per-call APIs never fires; there is no payment step to intercept. That also means no spend policy, no facilitator, and no per-caller identity, so the provider can only rate-limit by IP.
For agents buying data mid-task, keyless endpoints are the zero-friction tier; when you need guarantees, metered per-call billing in USDC on Base fits the same workflow (our x402 monetization notes).
How do you call a no-key weather endpoint (request and response example)?
curl examples you can paste
Open-Meteo takes plain query params, no signup, no header tricks:
curl "https://api.open-meteo.com/v1/forecast?latitude=40.71&longitude=-74.01¤t=temperature_2m,wind_speed_10m,weather_code&daily=temperature_2m_max,temperature_2m_min,precipitation_probability_max&temperature_unit=fahrenheit&forecast_days=3"
wttr.in is even lazier and returns a human-readable block, which is fine for a quick check but poor for parsing:
curl "wttr.in/New+York?format=j1"
The format=j1 flag is the difference between a terminal toy and a JSON payload your agent can actually read.
Response fields that matter to an agent
The long paragraph worth quoting on its own: an agent does not need a full forecast object, it needs four things, and you should request only those. First, current.temperature_2m for the immediate decision. Second, weather_code, because Open-Meteo returns WMO integers (0 is clear, 61 is rain) and your prompt or tool description should map them to plain English once rather than trusting the model to guess. Third, daily.precipitation_probability_max for the "should this errand wait" call.
Fourth, the utc_offset_seconds field, because a "3pm forecast" is useless if your agent assumes UTC and the location is Denver. Trim the request to those params and you cut response size by an order of magnitude, which matters when every token and every call has a cost attached. The same discipline applies to paid per-call endpoints: if your agent wraps weather behind an MCP tool, expose exactly those four fields and nothing else. That is the pattern we use building hosted MCP servers (https://scriptmasterlabs.com/chatgpt-sites-hosted-mcp-servers), where a narrow tool contract beats a fat one for both cost and reliability.
How do no-key weather APIs compare on data freshness and forecast depth?
Current conditions vs hourly vs multi-day
Open-Meteo is the strongest keyless option for depth: it returns current conditions, hourly data out to 16 days, and daily aggregates in one call, with models documented on its Open-Meteo docs page. It is free for non-commercial use under its terms, so read the fair-use terms before pointing production traffic at it.
wttr.in and Open-Meteo serve different jobs:
| Endpoint | Current | Hourly | Multi-day | Best for |
|---|---|---|---|---|
| wttr.in | Yes | Short range | ~3 days | One-off curl checks |
| Open-Meteo | Yes | Yes | 16 days | Agent forecast workflows |
If your agent only needs "is it raining now," wttr.in is fine. If it needs to plan across days, hourly granularity from Open-Meteo is what you want.
The trade-off is accountability: keyless endpoints give you no spend policy or per-call receipt. When a task needs verified, auditable data calls, that is the point where a paid per-call API earns its keep. We document our own machine-payable APIs at scriptmasterlabs.com/api-docs.
What are the rate limits and terms for keyless weather APIs?
Fair-use ceilings
No-key endpoints throttle by IP, not by account, so your agent shares a ceiling with everyone behind the same NAT or proxy. Open-Meteo documents free use at 10,000 requests per day per IP, with 600 calls per minute; 7Timer! and wttr.in publish no hard numbers and can drop or slow responses under load at any time. Because there's no contract, a throttle is a 402-style challenge you can't appeal. Build retry with jittered backoff and a local cache keyed on lat/lon plus hour before you call any of these from a loop.
Attribution and commercial-use clauses
Open-Meteo's terms allow commercial use under CC-BY attribution; wttr.in's terms are looser and its console format is aimed at humans, not parsers. Read each provider's terms page before an agent spends on your behalf. We hold our own paid endpoints to the same test: spend policy and per-call pricing are stated up front at https://scriptmasterlabs.com/agent-economy-os.
Can agents or scripts use keyless weather APIs without signup friction?
Yes. A keyless endpoint needs no account, no token, no consent screen, so an agent can fetch weather mid-task on the first try. Open-Meteo's docs state the API is free for non-commercial use with no key required (https://open-meteo.com/en/docs).
Wrapping a keyless endpoint as an MCP tool
Write one tool with a static name, a JSON schema for latitude, longitude, and current parameters, and a fetch to the endpoint. Publish the tool list statically rather than building it from a live fetch, because directories like mcprush read your package, not your runtime. Our agent API buyers guide covers the same pattern for paid per-call tools.
Failure modes agents hit
Agents pass city names instead of coordinates, so your tool needs a geocoding step or it 400s. They also ignore the timezone parameter and misread local times. Cache responses briefly: agents retry aggressively, and rate limits apply per IP.
What are the security and reliability risks of keyless weather endpoints?
No contract, no recourse
A keyless endpoint comes with no terms, no SLA, and no 402 challenge to price a failure. If the operator throttles you, blocks your user agent, or shuts down tomorrow, your agent has nothing to point at. There is no facilitator holding funds in escrow and no receipt trail in USDC on Base; you simply get a 503 and a broken workflow. Treat every keyless call as best-effort and wrap it in a timeout plus a fallback source.
Schema drift and silent changes
Keyless endpoints can change response fields, units, or coordinate formats without notice, because nothing in the request authenticated you as a consumer owed stability. An agent that cached yesterday's field names will read null mid-task and keep going, which is worse than a hard failure. Pin a schema check on every response: verify the fields you actually use exist and parse before the agent spends tokens reasoning over garbage. If a provider matters enough to depend on, that check is what tells you when to graduate to a contract you can hold someone to.
When should you switch from a no-key weather API to a keyed or paid one?
A decision framework with numbers
Three thresholds tell you keyless is done. Volume: if your agent polls weather more than a few thousand calls a day, you are one shared-IP rate limit away from failed tool calls. Freshness: keyless endpoints like weather.gov's public API serve US government forecasts with no SLA; if your agent makes spend decisions on the data, you want a contract for how stale a reading may be. Liability: once weather gates a payment, a shipment, or an agent's spend policy, a free endpoint's "best effort" terms are the wrong foundation. Any of these hit, graduate to a keyed plan or a machine-payable API.
Running our own x402 model through the same criteria
ScriptMasterLabs sells paid per-call APIs over x402, settled in USDC on Base, no signup. Honest scoring against our own framework: we win on liability, since each call is paid and auditable on-chain. We lose on volume economics, because per-call USDC micropayments beat flat keyed pricing only at low-to-medium call rates. And our weather-style data is only as fresh as its upstream provider, which we state rather than guarantee.
What about other no-key APIs: crypto, currency, images, movies?
The same pattern holds. CoinGecko serves price data with no key at modest rate limits; Frankfurter serves currency rates keyless from ECB data; picsum.photos serves placeholder images; TVMaze serves TV and movie data. All four answer a plain GET with JSON or an image, so an agent can call them mid-task with no signup.
The differences are depth and freshness, not access. Crypto endpoints update fast; currency endpoints update once per ECB publishing day; placeholder images are static by design. Apply the same test as weather: does the keyless endpoint's freshness and rate ceiling cover your task? If not, graduate to a keyed or pay-per-call option the same way.
FAQ
Is OpenWeather API usable without a key?
No. OpenWeather requires a signup and an API key even on its free tier, so it fails the plain-GET test. If you want a truly keyless forecast endpoint, Open-Meteo and wttr.in both answer an unauthenticated GET, and api.weather.gov serves US forecasts with no account at all.
Do I need to attribute or credit a keyless weather API in my app?
Open-Meteo's terms require CC-BY attribution, even for commercial use, so credit the provider in your app. wttr.in is looser but publishes no hard terms, so attribution is the safe default. Check each provider's terms page before shipping, since keyless access does not mean license-free access.
Can ChatGPT or an agent fetch weather without an API key?
Yes, if a tool wraps a keyless endpoint. Build one MCP tool with a JSON schema for latitude, longitude, and the fields you need, then fetch Open-Meteo or wttr.in directly. Agents pass city names instead of coordinates, so add a geocoding step or the call returns a 400.
What happens if a free no-key weather API goes down mid-task?
You get a 503 and a broken workflow with no recourse: no SLA, no receipt, no operator to appeal to. Throttling and outages are best-effort realities on shared-IP endpoints. Wrap every call in a timeout, retry with jittered backoff, cache by lat/lon plus hour, and keep a fallback source.
Are keyless weather APIs safe for commercial products?
For low-volume, non-critical reads, yes, provided you honor attribution terms like Open-Meteo's CC-BY clause and tolerate silent schema changes. Once weather gates a payment, a shipment, or an agent's spend decisions, best-effort terms are the wrong foundation; graduate to a keyed or paid per-call endpoint with a contract.