WeatherLabs turns the world's operational forecast into a fast JSON API. Any latitude and longitude, every variable we publish, 209 forecast steps — no GRIB, no Zarr, no pipeline to run.
Ask for a point, a region, a journey, or a whole global field. You get back clean JSON (or a binary grid) — units labelled, valid-times attached, ready to plot or pipe into your business logic. Not writing the code yourself? Put a live forecast on your website or in your spreadsheet — send this page to your developer, or start from a ready-made integration.
The API returns the model's native SI units — temperatures arrive in kelvin (°C = K − 273.15); the Explorer converts for display.
One coordinate in, the full 16-day series out — multiple variables per call.
Every waypoint of a route in one call, legs fetched concurrently — same endpoint, POSTed.
A country or continent aggregated at any step — true polygon boundaries, same endpoint.
Any rectangle you can draw on a map — min/mean/max at the step you pick.
The whole planet for one step — JSON, or float32 binary for the GPU.
Every response carries units, valid-times, and exactly what it read and billed.
var= away.Click a variable to see what it is and how to ask for it — then open it on the
live globe. Surface fields are 2-D; pressure-level fields take a level= in hPa.
On the gefs ensemble model, surface variables also come as
_p10/_p90
spread percentiles alongside the mean — included from the Developer tier up.
The interactive Explorer renders a live global field on the GPU as a single texture — scrub through 16 days of forecast, switch peril, click for a point series, plot a route, or drag a box. Every interaction shows the exact API call it made, ready to copy.
Launch the Explorer →Everything is a view of the same forecast: one endpoint answers “what's the weather going to be?”, and a small set of helpers reshape or describe it.
The forecast series at any latitude/longitude — every variable, up to 209 steps, nearest-cell
or bilinear, time-selectable with steps= (lead hours),
time= or start/end.
Pin {cycle} to an immutable run id, or use
latest.
Daily min/max/mean and physically correct precip totals, derived server-side.
A journey: one series per waypoint, fetched concurrently with shared-tile coalescing.
Aggregate a named polygon region or bounding box — one step per request, cold-fast.
The other endpoint: a full lat/lon field for one step — JSON or binary fast-path.
Every published model, its grid and latest cycle.
Every retained cycle — pin one for immutable URLs.
Cycle metadata, the live variable list, and named regions.
Your tier, live quota and entitlements — costs almost nothing.
Full reference, parameters and examples in the documentation — or run them live in the Playground.
The serving store is laid out so a point's entire forecast lives in one compressed tile: a point query is a single object read — typically tens of milliseconds cold, sub-millisecond warm server-side. Don't take our word for it: measure it from your own browser, right here.
/v1/gfs/2026070500/… is immutable —
cache it in your CDN, your browser, or a plain dict; the bytes never change.Hover a tile to see the kind of question it answers — and the exact call that answers it. Click to open that query on the live globe.
Simple, metered plans: billing is by the volume of decoded forecast data your requests return, and quotas are per account. No per-seat fees, no overage surprises — when you hit your allowance, requests pause until reset or you upgrade.
In everyday terms: a website showing a five-day outlook for one town fits Free; prototyping with coarse grids and regions is Developer (£3); a 10-day outlook in a small product is Hobby; production dashboards drawing native-resolution grids start at Starter.
Resolution caps apply to gridded shapes (grid and region) only — point queries sample the native 0.25° grid on every tier, including Free (which has no gridded endpoints, hence no resolution figure on its card).
Anyone can try the Explorer and Playground free — no key needed during the beta. You only need an account key to call the API from your own code.
| Request | Billed (32 KiB minimum) | Of a 500 MB plan |
|---|---|---|
| Point / daily query | 32 KiB (the floor) | ~0.006% |
| Region aggregate (one step) | 32 KiB (the floor) | ~0.006% |
| Global grid step · 1.0° | 254.5 KiB | ~0.05% |
| Global grid step · 0.5° | ~1 MB | ~0.2% |
| Global grid step · 0.25° native | 4.15 MB | ~0.8% |
Billing counts the values a response decodes (values × 4 bytes), with a 32 KiB floor per
request — the floor is a billing minimum, not a payload size (a single-variable point actually
decodes well under 1 KiB). Quotas use SI units (1 GB = 10⁹ bytes) and are shared across
your whole account.
Every response carries X-Billed-Bytes and live quota
headers, so there are no surprises. Full breakdown in the
pricing & billing docs.
A valuable forecast is often the most important data an industry consumes — it prices power, routes ships, schedules harvests, and settles insurance. Yet using it still means wrestling GRIB files, regridding pipelines and petabyte archives. WeatherLabs exists to delete that work. Each day we ingest the operational global forecast, regrid and consolidate it into a time-major tiled store, and serve it through a stateless Rust API — the hard parts happen once, on our side, so they never happen on yours.
The full operational GFS run — every variable, every level we publish, 16 days ahead at native 0.25° — published daily (the 00z run) and served from memory-speed tiles.
The same paths, a second {model}:
gefs, the 31-member GEFS ensemble —
mean plus p10/p90 bounds, surface variables, 3-hourly to +240 h. Additional physical and AI
models are on the roadmap and will join the same way.
We're building towards world-leading research on next-generation forecasting — machine learning grounded in atmospheric physics.
Speed is a feature of the data, not a tier. We profile and optimise the serving path relentlessly — tile layout, caches, binary formats — so the fastest query is the default one.
/v1/gfs/2026070500/…)
are immutable and carry year-long Cache-Control headers;
latest URLs revalidate every ~30 s.
We retain the newest 12 cycles per model (~12 days at the current daily cadence) — a pinned URL
answers identically while its cycle is retained.