Introducing the WeatherEdge API: A Forecast That Ships Its Own Error Bars

This is an announcement about a data product. It is not financial, investment, or trading advice, and nothing here is a recommendation to do anything.

The dashboard is one screen, and one screen only fits one way of looking at a day. Some people want to look at it differently — run the numbers against their own notes, keep a log of how the model behaved before a market moved, or get a message when a city's read shifts while they're doing something else.

That's what the WeatherEdge API is for. Same model that drives the dashboard, as JSON, in your own code.

It's live now, covering all fifteen cities we forecast: Atlanta, Austin, Boston, Chicago, Dallas, Denver, Houston, Las Vegas, Los Angeles, Miami, New York, Philadelphia, Phoenix, San Francisco, and Seattle.

A forecast with the doubt attached

Here's an entire response:

{
  "station": "KMDW",
  "location": "Chicago",
  "airport": "Chicago Midway Airport",
  "date": "2026-08-14",
  "asOf": "2026-08-14T18:05:00Z",
  "predictedHighF": 86,
  "sigmaF": 0.9,
  "confidence": "sharp"
}

Most weather APIs give you the first number and stop. predictedHighF on its own is the least interesting field here.

sigmaF is the product. It's the model's own uncertainty in °F — how wide it thinks the day is. A predicted high of 86 with σ 0.9 and a predicted high of 86 with σ 3.4 are not the same claim, and any code that treats them the same is throwing away the part that should be driving its behavior.

confidence is the same information as a plain bucket, so you can branch on it without hardcoding thresholds:

Tier	σ	Read it as
sharp	≲ 1.5 °F	Tight, high-conviction
usable	1.5–2.5 °F	Solid
broad	2.5–4 °F	Directional only
too_broad	≳ 4 °F	Very uncertain

Nine cities, one request

Omit location and you get the whole slate in a single call:

curl "https://www.prilo-weatheredge.com/api/v1/forecast" \
  -H "Authorization: Bearer $KEY"

Address any city by name or ICAO code, case-insensitive — Chicago and KMDW both work. Forecasts refresh about every five minutes, and responses carry Cache-Control headers that say so, so there's no reason to poll harder than that.

The endpoint we'd point you at first

/forecast/history returns what we said at each hour of a past day, alongside how it actually settled:

curl "https://www.prilo-weatheredge.com/api/v1/forecast/history?location=Houston&date=2026-08-11" \
  -H "Authorization: Bearer $KEY"

You get an hourly array — asOf, localHour, predictedHighF, sigmaF, confidence — and a settled object with the official high once it's known.

This is the endpoint that lets you check our work. Not our summary of our work: the actual sequence of numbers we published, hour by hour, against the number that actually happened. You can compute our error yourself, find out whether our σ is honest, and see which regimes we drift on.

We publish a calibration scorecard in the Discord, and we post the misses. This endpoint means you never have to take our word for any of it.

/settlement gives you the realized daily high on its own, from the official NWS CLI report, with a final flag so you can tell a settled number from a preliminary one.

What it isn't

The fastest way to be disappointed by a tool is to be sold the wrong idea of it.

• It isn't a raw-observation feed. You get the model's view, not a METAR firehose. If you want raw observations, get those from NOAA directly — they're free, and we'd be a worse source.
• It doesn't return per-bracket probabilities. No "90-91°: 43%" field. You get a predicted high and a σ; converting that into bracket probabilities is your model's job, not ours.
• It's fifteen cities, not the country. The ones with liquid daily-high markets. If the city you trade isn't on the list, tell us and it goes on the list — that's how Denver, Philadelphia, Las Vegas, Boston, Phoenix and Seattle got added.
• The model is wrong regularly. Sometimes by several degrees, sometimes on days it felt confident about. The API reports what the model thinks, including when the model is about to be wrong. That's what σ is for.

Point your coding agent at it

There's a plain-Markdown reference written specifically for AI assistants:

https://www.prilo-weatheredge.com/api/v1/llms.txt

Give that URL to Claude Code, Cursor, or whatever you're building with, and it has the complete API — endpoints, fields, conventions, error codes — without you writing an integration by hand. There's also an OpenAPI 3.0.3 document if you'd rather generate a client.

Most people are up in about two minutes: create a key under Account → API, curl /forecast, done.

Limits and practicalities

• 120 requests/minute sustained, bursting to 240.
• 50,000 requests per rolling 30 days.
• Every response carries X-RateLimit-* headers; on a 429, wait the Retry-After seconds.
• Keys are secrets — server-side only, never in a browser bundle or a committed file. You can create, label, and revoke them yourself under Account → API, and a revoked key stops working immediately.

What it costs

$49.99/month, or $479/year.

The API is a standalone add-on, not a tier. It stacks on whatever plan you're already on, including Free — buying it doesn't change your dashboard access, and upgrading your dashboard plan doesn't get you API access. If you only want the data, staying on Free costs you nothing extra on the API side.

Keys belong to your account rather than to the subscription, which has one practical consequence worth knowing: nothing gets rotated when your billing changes. Subscribe, lapse, resubscribe — same key, no redeploy.

Get an API key →

The trader's read

• A forecast without an error bar can't be sized. sigmaF is the field that should drive your code's behavior, not predictedHighF.
• Use /forecast/history to audit us before you trust us. It exists so you don't have to take our calibration claims on faith.
• The model's view is an input, not an answer. It doesn't know your risk tolerance, your account, or your other positions.
• If you want raw observations, go to NOAA. If you want a model that publishes how wrong it expects to be, that's this.

v1 is stable — existing fields and endpoints won't change meaning or vanish under you without a new major version. But stable isn't finished: if a field is missing, a limit is wrong, or an endpoint would be more useful shaped differently, tell us. Reply to any email, or find us in the Discord. We read all of it, and what gets built next is decided by the people actually calling it.

---

Not financial advice. Nothing here is a recommendation to buy or sell anything. Temperature models and prediction markets are both uncertain, our model is wrong on a regular basis, and trading carries real risk of loss — including losing everything you put in. Trade your own view, at a size you can afford.