Energy & Utilities
Weather-Based Demand API
You already know your sales move with the weather. What you probably do not have is a number you can staff and order against three days out.
- Grocery and retail chains
- Hospitality groups
- HVAC service companies
- Workforce scheduling vendors
- Field service platforms
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Weather sensitivity in commerce is well known and badly used. Everyone in a retail operations meeting agrees that ice cream sells in a heatwave and soup sells in a cold snap, and almost nobody has a per-store coefficient they would commit an order quantity to. The result is a forecast built on last year's same week, with a manager overriding it on instinct when the outlook looks unusual.
The relationship is also more interesting than it first appears. It is rarely linear and rarely instantaneous. The first warm weekend of spring produces a far larger lift than the fourth one at the same temperature, because the response is to the change rather than the level. Rain suppresses footfall at a high street site and barely touches a mall unit. A cold spell drives heating callouts with a lag of a day or two, then a backlog that outlasts the weather.
For heating and cooling services the same data answers a different question: how many engineers will be needed next week, and where. Breakdown volumes follow degree days and cold-snap onset closely enough to roster against, which matters because the alternative is overtime during the week when every competitor is also short of engineers.
Who buys this
Grocery and retail chains, Hospitality groups, HVAC service companies, Workforce scheduling vendors, Field service platforms
What the API returns
What comes back
- Demand forecasts per site, product category and service type
- Weather sensitivity coefficients estimated per site and category
- Non-linear and lagged responses, including first-warm-day and cold-onset effects
- Degree-day based volume forecasts for heating and cooling work
- Expected footfall effects from rain, wind and temperature
- Uplift and suppression attributable to weather, separated from trend and promotion
- Staffing and ordering implications expressed in your own units
- Measured forecast error per site and horizon
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/forecast/demand | Weather-driven demand forecast for sites and categories |
| GET | /v1/sites/{id}/sensitivity | Estimated weather sensitivity coefficients for one site |
| POST | /v1/forecast/service-volume | Expected breakdown or callout volume by area |
| POST | /v1/attribution | Split historical demand into weather, trend and promotion effects |
| GET | /v1/degree-days/{region} | Heating and cooling degree day history and outlook |
| POST | /v1/sites | Register sites with location, type and category mapping |
Request and response
illustrativeRequest
{
"sites": ["str_0188", "str_0192"],
"categories": ["chilled_drinks", "soup_and_ready_meals", "bbq"],
"horizon_days": 10,
"include": ["sensitivity", "attribution", "intervals"]
}Response
{
"issued_at": "2026-10-22T05:00:00Z",
"sites": [
{
"site_id": "str_0188",
"days": [
{
"date": "2026-10-24",
"forecast_temp_max_c": 19.4,
"categories": [
{ "category": "chilled_drinks", "baseline_units": 412,
"weather_uplift_pct": 17.8, "p50_units": 485, "p10_units": 441, "p90_units": 538 },
{ "category": "soup_and_ready_meals", "baseline_units": 206,
"weather_uplift_pct": -11.2, "p50_units": 183, "p10_units": 164, "p90_units": 205 }
]
}
],
"sensitivity": {
"chilled_drinks": { "pct_per_degree_above_16c": 4.1, "rain_effect_pct": -6.2,
"first_warm_day_bonus_pct": 9.4 },
"soup_and_ready_meals": { "pct_per_degree_below_12c": 3.6, "lag_days": 1 }
}
}
],
"confidence_note": "Days 1-5 weather-driven; days 6-10 widen substantially as forecast skill decays."
}Where the data comes from
| Your sales or job history | Daily or hourly volumes per site and category, ideally two full years so each season appears at least twice. Without this there is no sensitivity to estimate |
| Weather observations | Historical temperature, precipitation, wind and humidity at or near each site. National observation networks are typically open; some met services licence their archives commercially |
| Weather forecasts | Open global ensembles for the forward horizon. Higher-resolution commercial forecasts improve near-term accuracy but usually prohibit redistributing the underlying values |
| Your promotion and pricing calendar | Essential, not optional. Without it the model attributes promotional lift to whatever the weather happened to be doing |
| Site reference data | Location, format, indoor or high street, catchment type. Rain affects a retail park unit and a seafront kiosk very differently |
| Local event calendars | Where available and permitted — a festival or fixture overwhelms the weather effect and otherwise shows up as unexplained error |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Per-site, per-category response curves rather than a single chain-wide coefficient, since format and catchment change the relationship more than most operators expect
- Non-linear temperature response with explicit threshold and change-based terms, capturing the first-warm-day effect that a linear fit averages away
- Lag structures per category — heating callouts peak a day or two after a cold snap begins, drink sales respond same day
- Promotion and price effects fitted jointly with weather so the two are not confounded, which is the most common failure in this kind of model
- Hierarchical pooling so a new or low-volume site borrows from comparable sites instead of fitting noise
- Degree-day aggregation with site-specific base temperatures, estimated rather than assumed at the conventional 15.5 degrees
- Interval widths that grow with weather forecast horizon, so a day-nine number is visibly less certain than a day-two one
- Walk-forward validation by season, with error reported per site — and sites where weather explains too little variance flagged as such rather than given a spurious coefficient
What it changes for the business
Waste and markdown
Ordering against a weather-adjusted forecast reduces both stockouts in a heatwave and markdowns after it.
Labour cost
Rostering to expected volume cuts the overtime and agency spend that follows a cold-snap backlog.
Planning conversations
A per-site coefficient replaces the argument about whether the weather will matter this week.
Service levels
Field service teams sized to forecast demand hold response times through the weeks that usually break them.
How it fits into your product
How it embeds
- Site registration endpoint so new locations start forecasting without manual configuration
- Forecasts shaped to your ordering and rostering deadlines, not a generic daily cadence
- Output in your own units — cases, trays, engineer hours — rather than abstract indices
- Ingestion from your EPOS, job management or data warehouse on a nightly schedule
- Webhooks on significant forecast changes so an ordering deadline is not missed
- White-label delivery for scheduling and field service vendors reselling to operators
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How much history do you need?
Two years is the honest answer, because each season has to appear at least twice before a weather coefficient can be separated from a trend. One year gives something usable with wide intervals. Below a year we would fit pooled coefficients from comparable sites and tell you that the site-specific effect is borrowed rather than measured.
How far ahead is the forecast useful?
It follows weather forecast skill, so days one to five are genuinely decision-grade, days six to ten are directional, and beyond that it is seasonal climatology. Since ordering lead times often run past five days, we return the wider intervals rather than a confident point value and let your ordering rules decide how much weight to give them.
What if weather does not actually drive our sales much?
Then the model will say so, and we would tell you during the prototype rather than after the build. For some categories and formats the weather coefficient is small and swamped by promotion and footfall trend. That is a real result. Fitting a visible coefficient to a category that does not have one is the easiest way to make a forecast worse than the one you already use.
Can you include local events?
Where there is a permitted source for them, yes, and they help a lot at affected sites. Event calendars are patchy and the terms of use on aggregator sites frequently prohibit commercial scraping, so coverage is a licensing question rather than an engineering one. We would scope what is actually available for your locations during discovery.
Do you need our promotion data?
Yes, and this one is not negotiable if you want trustworthy coefficients. A model without a promotion calendar will quietly credit the weather for a price cut, and the resulting sensitivity estimates will be wrong in ways that look plausible. If that data is hard to extract we would rather solve the extraction than model around it.
Related blueprints
Energy Demand Forecasting API
Electricity and gas load forecasts by region, network segment and customer group, for utilities, retailers and network planners.
Crop Yield Forecasting API
Expected yield by crop, location and season, with honest uncertainty, for agritech platforms, insurers, lenders and grain buyers.
Electricity Price Forecasting API
Wholesale electricity price forecasts and spike alerts by market and delivery hour, embedded in energy trading and retail software.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.