Energy & Utilities
Renewable Generation Forecast API
Wind output is a cubic function of a quantity nobody can measure precisely in advance. That is the entire difficulty, and it is why generation forecasting stays valuable.
- Wind farm operators
- Hydro operators
- Balancing responsible parties
- Grid operators
- Energy trading desks
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
A wind turbine's power curve is steep in the middle. Between roughly five and twelve metres per second, a one metre per second error in the wind speed forecast becomes a very large error in megawatts. That non-linearity is why wind forecasting does not get solved by better weather models alone — the same meteorological skill produces much larger revenue consequences at a wind farm than at a solar site.
Hydro has the opposite character. Run-of-river output follows catchment inflow, which responds to rainfall and snowmelt over days to weeks, and reservoir output is partly a decision rather than a forecast. The two need different treatment, though trading desks want them on one interface because they are hedging one portfolio.
The practical work is site-specific calibration. Hub-height wind from a gridded model is not the wind at a particular turbine behind a ridge, and a farm's effective power curve drifts with blade erosion, wake effects at different directions, and curtailment that does not always arrive as a clean signal. Fitting the correction from the asset's own history is what separates a usable forecast from a weather feed with units changed.
Who buys this
Wind farm operators, Hydro operators, Balancing responsible parties, Grid operators, Energy trading desks
What the API returns
What comes back
- Forecast output per asset, zone and system at the market's settlement resolution
- Prediction intervals derived from weather ensemble spread, not fixed percentages
- Ramp event detection with expected magnitude and timing window
- Probability of output falling below configurable thresholds
- Hydro inflow outlook from catchment precipitation and snowpack
- Curtailment-adjusted versus unconstrained output, reported separately
- Zonal aggregation with spatial correlation applied
- Measured accuracy by horizon, asset and wind speed band
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/assets/{id}/forecast | Output forecast for one wind or hydro asset |
| POST | /v1/portfolio/forecast | Aggregated forecast across assets or a market zone |
| GET | /v1/zones/{zone}/forecast | Zonal renewable output forecast |
| GET | /v1/assets/{id}/ramps | Expected ramp events over the horizon |
| GET | /v1/hydro/{catchment}/inflow | Catchment inflow outlook |
| GET | /v1/accuracy | Error statistics by horizon, asset and conditions |
Request and response
illustrativeRequest
{
"asset_ids": ["wf_north_ridge", "wf_glenmore", "hydro_tay_run"],
"horizon_hours": 96,
"resolution": "PT30M",
"include": ["intervals", "ramps", "curtailment_adjusted"]
}Response
{
"issued_at": "2026-10-22T06:00:00Z",
"assets": [
{
"asset_id": "wf_north_ridge",
"capacity_mw": 148.5,
"forecast": [
{ "start": "2026-10-22T18:00:00Z", "p50_mw": 96.2, "p10_mw": 48.1, "p90_mw": 131.4 },
{ "start": "2026-10-23T06:00:00Z", "p50_mw": 22.8, "p10_mw": 6.4, "p90_mw": 61.0 }
],
"ramps": [
{ "from": "2026-10-23T01:00:00Z", "to": "2026-10-23T04:00:00Z",
"direction": "down", "expected_mw": -71.0, "timing_uncertainty_hours": 2.5 }
],
"low_output_probability": { "below_20_pct_capacity": 0.34 }
}
],
"hydro": [
{ "catchment": "tay_upper", "inflow_outlook": "rising",
"snowpack_contribution": "none", "confidence": "medium" }
],
"zone_total_p50_mw": 1842.6
}Where the data comes from
| Numerical weather prediction ensembles | Hub-height wind, pressure and precipitation. Open global ensembles such as GFS and the ECMWF open dataset are commercially usable; high-resolution regional runs are licensed and usually restrict pass-through |
| Your SCADA history | Per-turbine or per-farm output, availability and nacelle wind measurements. This is what makes the site correction possible and nothing substitutes for it |
| Transmission operator transparency data | Published actual generation by unit and zone, used for zonal models where you do not own the assets. Normally publishable with attribution |
| Curtailment and dispatch instructions | Without these, every network-constrained hour looks like a forecast failure and corrupts the training set |
| Hydrological observations | River gauge levels, reservoir storage and snowpack. Often open from national agencies, with licences that vary by country and sometimes forbid commercial redistribution |
| Turbine specifications | Manufacturer power curves as a starting point, replaced by the fitted effective curve once enough history exists |
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.
- Site-specific transfer functions mapping gridded wind to measured output, fitted per asset and per wind direction sector to absorb wake and terrain effects
- Ensemble members propagated individually through the power curve, which is essential because the curve's non-linearity means the mean of the inputs is not the input of the mean
- Ramp detection as a distinct model output, since a desk cares about timing uncertainty on a steep change more than about average error
- Curtailment periods masked from training and reported separately at inference, so constrained output and forecast error stay distinguishable
- Hydro modelled as a catchment response with lagged precipitation and snowmelt features, and reservoir assets treated as partly operator-driven rather than purely meteorological
- Effective power curve re-estimated on a rolling window to track blade degradation and availability changes
- Spatial correlation for zonal aggregation, estimated from historical co-movement rather than assumed from distance
- Accuracy reported by wind speed band and horizon, with interval calibration monitored continuously — under-wide intervals are the common and expensive failure
What it changes for the business
Imbalance cost
Better nominations mean less volume settling at imbalance prices, which is the most direct measurable saving.
Ramp preparedness
Timing windows on large ramps let a desk or control room position before the change rather than react to it.
Maintenance scheduling
Low-wind windows identified in advance are the cheapest time to take a turbine offline.
Trading confidence
Calibrated intervals let a desk size positions against stated uncertainty instead of a point number.
How it fits into your product
How it embeds
- Forecast delivery on a schedule aligned to gate closure, not on a generic hourly cadence
- SCADA ingestion by push, historian pull or flat file drop, whichever your operations stack already does
- Portfolio and zonal endpoints so one call covers a whole balancing position
- Webhooks on ramp alerts and low-output probability thresholds
- Deployment inside your own environment where SCADA data cannot leave the operational network
- Forecast band and actual-versus-forecast series ready for your control room displays
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 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
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 can wind forecasting actually get?
Day-ahead farm-level error typically sits in the high single digits to mid teens as a percentage of capacity, and it depends heavily on terrain and on how much SCADA history exists. Beyond about five days the skill approaches climatology. We report measured error by horizon rather than quoting a headline figure, because a single number across all conditions hides the hours you care about.
Why can you not forecast ramp timing precisely?
Because a front arriving two hours late shifts a seventy megawatt ramp two hours later, and current weather models do not pin frontal timing to the half hour at multi-day range. We return a timing window with explicit uncertainty instead of a single timestamp. A desk can hedge a window; it cannot hedge a false precision.
Can you forecast hydro as reliably as wind?
Run-of-river, reasonably — catchment response to rainfall is slower and more predictable than wind. Reservoir hydro, no, and we would not claim it. Output there is largely an operator decision about when to release water against expected prices, which is a behavioural question rather than a meteorological one. We model inflow, which is the forecastable part, and leave dispatch to you.
Can we redistribute these forecasts to third parties?
The forecast values, yes. Where it gets complicated is the inputs: high-resolution commercial weather licences frequently forbid redistribution and some restrict derived products as well. If redistribution is part of your business model we would build on open ensembles and operator transparency data, measure the accuracy gap honestly, and let you decide whether the licensed uplift is worth the constraint.
What about new assets with no history?
They get a manufacturer power curve with a generic terrain correction and visibly wider intervals. It is noticeably worse than a calibrated asset, and the API labels it as uncalibrated rather than presenting the two as equivalent. Three to six months of SCADA usually closes most of the gap.
Related blueprints
Solar Production Forecast API
Generation forecasts for solar assets with uncertainty bands and performance anomaly detection, embedded in monitoring and asset management platforms.
Energy Demand Forecasting API
Electricity and gas load forecasts by region, network segment and customer group, for utilities, retailers and network planners.
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.