Issue Nº 28 — Sep 10, 2026
The US National Weather Service API redirects your coordinates and blocks a blank User-Agent
Issue twenty-eight covers the US National Weather Service API, the free forecast and alerts service behind api.weather.gov. It needs no key. This session queried it live. A precise coordinate gets rounded and redirected, a 404 for a bad path looks the same as a 404 for missing data, and a blank User-Agent header gets blocked before the API ever sees the request.
A precise coordinate gets rounded, then redirected
GET /points/39.74561234,-97.08921234, queried live this session, returned 301 with a location header of /points/39.7456,-97.0892. The API keeps four decimal places and redirects anything more precise to the rounded value.
Four decimal places is about 11 metres of ground. That is fine for most forecasts. But a client that logs GPS coordinates to six decimal places should expect a redirect on almost every call.
A client that does not follow redirects gets a 301 body and no forecast data. The fix is simple: follow the redirect, or round coordinates to four decimal places before the first request.
Two 404s, one status code, two different meanings
GET /nope-not-a-path, queried live this session, returned 404. Its type field read "https://api.weather.gov/problems/NotFound". That is a routing error: the path itself does not exist.
GET /points/0,0, queried live this session, also returned 404. But its type field read "https://api.weather.gov/problems/InvalidPoint". That is a coverage gap: the path is valid, but no forecast data covers that spot.
Both bodies follow the RFC 7807 problem+json format. Both carry an instance field, a link back to the specific request. Fetching that link, queried live this session, itself returned 404. The debug pointer the API hands back does not resolve.
Code that branches on the 404 status alone cannot tell a bad path from an uncovered point. Branch on the type field instead.
A blank User-Agent gets blocked before the API sees it
GET /points/39.7456,-97.0892 with an empty User-Agent header, queried live this session, returned 403. The block came from an Akamai edge server, not the weather API itself. The same request with curl's default User-Agent string returned 200.
No credential is required to call this API. Any User-Agent string, not just a specific one, satisfies the check. This entry stays keyless.
A browser fetch call, or a proxy that strips headers, can still send a blank User-Agent and get blocked. Set a real User-Agent string on every request, even though no signup is needed.
US Weather, by the numbers
No fixed public rate limit is published; exceeding an undisclosed threshold returns an error, typically clearing within ~5 seconds. Every request must include a descriptive User-Agent header identifying the app (e.g. contact info) — direct client requests are rarely throttled, but requests routed through shared proxies are far more likely to hit the limit.
- GET/points/{latitude},{longitude}
- GET/gridpoints/{wfo}/{x},{y}/forecast
- GET/gridpoints/{wfo}/{x},{y}/forecast/hourly
- GET/alerts/active
- GET/stations/{stationId}/observations/latest