Energy & Utilities
Energy Demand Forecasting API
Load is the most forecastable thing in energy and still the most expensive thing to get wrong, because every other number in the business is computed against it.
- Energy retailers
- Distribution network operators
- Balancing responsible parties
- Utility billing and CIS vendors
- Demand response aggregators
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
Demand forecasting is unusual in that the baseline is genuinely good. Temperature, day of week, time of day and a holiday calendar explain most of the variation in aggregate load, and a competent model gets within a few percent at system level. That accuracy is also the trap: because the baseline is strong, the remaining error concentrates in exactly the conditions where being wrong costs the most.
Underneath the aggregate, structure is shifting. Rooftop solar has turned midday net demand down and in some networks inverted the daily shape. Heat pumps are moving the winter peak and sharpening its temperature sensitivity. Electric vehicle charging adds a load that responds to tariff design rather than weather. A model fitted on five-year-old patterns forecasts a network that no longer exists.
The segment level is where most commercial value sits and where the data is worst. A retailer wants demand by customer cohort to settle positions; a network operator wants it per substation to plan reinforcement. Half-hourly settlement data, smart meter reads of uneven quality and non-half-hourly profile classes all have to be reconciled before the model sees anything.
Who buys this
Energy retailers, Distribution network operators, Balancing responsible parties, Utility billing and CIS vendors, Demand response aggregators
What the API returns
What comes back
- Load forecasts at system, zone, substation and customer-cohort level
- Prediction intervals with weather uncertainty propagated
- Peak timing and magnitude forecasts for the forecast period
- Temperature sensitivity coefficients per segment, reported explicitly
- Behind-the-meter solar adjustment separating gross from net demand
- Weather-normalised demand for year-on-year comparison
- Holiday, school term and special event adjustments
- Backtest error by segment, horizon and temperature band
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/forecast/{region} | Load forecast for a region or zone |
| POST | /v1/forecast/segment | Forecast for a defined customer cohort or substation set |
| GET | /v1/forecast/{region}/peak | Expected peak timing and magnitude |
| POST | /v1/forecast/scenario | Re-forecast under supplied weather or growth assumptions |
| GET | /v1/normalised/{region} | Weather-normalised demand history |
| GET | /v1/accuracy | Measured error by segment, horizon and conditions |
Request and response
illustrativeRequest
{
"region": "GB-SE",
"segments": ["residential_hh", "sme_nhh", "ev_tariff"],
"horizon_days": 7,
"resolution": "PT30M",
"include": ["intervals", "peak", "temperature_sensitivity"]
}Response
{
"region": "GB-SE",
"issued_at": "2026-10-22T07:00:00Z",
"unit": "MW",
"segments": [
{
"segment": "residential_hh",
"periods": [
{ "start": "2026-10-22T17:30:00Z", "p50": 2410.6, "p10": 2288.0, "p90": 2561.4 },
{ "start": "2026-10-23T17:30:00Z", "p50": 2588.2, "p10": 2401.7, "p90": 2790.9 }
],
"temperature_sensitivity_mw_per_c": -61.4,
"bm_solar_adjustment_mw_midday": -318.0
}
],
"peak": {
"expected_at": "2026-10-23T17:30:00Z",
"p50_mw": 4182.0,
"p90_mw": 4498.0,
"driver": "cold_evening_low_wind"
},
"accuracy_note": "7-day MAPE by segment at /v1/accuracy; residential error rises in shoulder seasons."
}Where the data comes from
| Your settlement and metering data | Half-hourly consumption by meter or aggregated cohort. The single most important input and the one nobody else can supply |
| Weather observations and forecasts | Temperature, humidity, wind chill and solar irradiance. Open national observation networks and global forecast ensembles are commercially usable; some national met service products are licensed per use case |
| System operator demand data | Published national and zonal load, useful for system-level models and as a reconciliation check |
| Calendar reference data | Public holidays, school terms, clock changes and major events. Mundane, and a frequent source of large errors when wrong |
| Embedded generation registers | Rooftop solar and small-scale capacity by area, needed to separate gross demand from net |
| Tariff and customer reference data | So EV and time-of-use cohorts are modelled as the distinct load shapes they are |
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.
- Separate models per segment rather than a single national model disaggregated downward — cohorts have genuinely different temperature responses and the top-down split loses that
- Non-linear temperature response with heating and cooling branches and lagged terms, since building thermal mass means yesterday's temperature still matters today
- Explicit behind-the-meter solar component estimated from embedded capacity and irradiance, because net demand series otherwise attribute a solar effect to the weather coefficient
- Hierarchical reconciliation so substation, zone and system forecasts sum consistently instead of contradicting each other
- Weather ensemble propagation for intervals, plus a separate model-uncertainty term, because on a mild stable day the weather spread is small and the residual uncertainty is not
- Peak forecasting treated as its own target, as the model that minimises average error across all periods is not the one that locates the annual peak
- Walk-forward validation by season and temperature band, reported per segment, with shoulder-season performance shown separately since that is where load models are weakest
- Drift monitoring on the temperature coefficients themselves — a moving coefficient is the earliest visible sign that electrification is changing the network
What it changes for the business
Imbalance and settlement cost
Segment-level accuracy reduces the volume a retailer settles at imbalance prices.
Network investment timing
Substation-level peak forecasts change when reinforcement is actually needed, which is a capital decision.
Hedging and procurement
Volume forecasts with honest intervals let a procurement team size hedges against stated risk.
Flexibility dispatch
Knowing where and when peak will land is what makes a demand response programme worth operating.
How it fits into your product
How it embeds
- Metering ingestion from your existing settlement feeds, data warehouse or flat file drops
- Forecast delivery on schedules aligned to your nomination and settlement deadlines
- Hierarchical endpoints so one integration serves both trading and network planning teams
- Scenario endpoint for planning teams to run their own growth and weather assumptions
- Deployment inside your environment where customer consumption data cannot leave
- Chart-ready series and peak summaries for embedding in your operational dashboards
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 accurate is this really?
At system level, day-ahead MAPE in the low single digits is normal and largely a solved problem. At substation or small-cohort level the error is several times larger, because the law of large numbers stops helping. We would measure both during the prototype on your own data and show you the segment-level numbers before you commit, rather than quoting the system-level figure and letting you assume it applies downward.
Where does the forecast stop being useful?
Out to about ten days it is a weather-driven forecast and decision-grade. Beyond that the temperature input becomes climatology and the output is a seasonal range rather than a half-hourly profile — still useful for procurement planning, not for nomination. We return the two as different products with different fields rather than extending one curve indefinitely.
Can you forecast electric vehicle charging load?
Partially, and with less confidence than the rest. EV load responds to tariff structure and charger availability more than to weather, so it shifts when you change your own tariffs. We model it as a separate cohort with its own features, and after any tariff change the recent history is partly invalid. That is a genuine limitation rather than a modelling detail.
Does our customer consumption data have to leave our systems?
No. In-environment deployment is common for this build precisely because half-hourly consumption data is both regulated and commercially sensitive. For a hosted option we would work from aggregated cohorts rather than meter-level records, and the aggregation thresholds would be set by your own compliance team.
What happens in unusual conditions — a heatwave or a public event?
Those are where the model is weakest, because by definition there are few comparable days in the history. The intervals widen, which is correct, but an unprecedented condition is genuinely extrapolation. We would flag such periods as low-confidence rather than returning a confident number, and for recurring events such as a major sporting fixture we fit an explicit adjustment once there is enough history to do so.
Related blueprints
Electricity Price Forecasting API
Wholesale electricity price forecasts and spike alerts by market and delivery hour, embedded in energy trading and retail software.
Weather-Based Demand API
Forecasts of weather-driven demand for retail, hospitality and heating or cooling services, delivered as a planning layer inside operational software.
Solar Production Forecast API
Generation forecasts for solar assets with uncertainty bands and performance anomaly detection, embedded in monitoring and asset management platforms.
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.