Energy & Utilities
Electricity Price Forecasting API
Your traders and your hedging desk both need the same number: what the next settlement period is likely to clear at, and how wrong that could be. Most of the value sits in the second half of that sentence.
- Energy retailers
- Power traders
- Utility software vendors
- Industrial energy managers
- Flexibility 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
Day-ahead and intraday power markets produce a price every settlement period, and almost every participant has some view on where it lands. The ordinary case is close to forecastable — load follows weather and the calendar, the merit order is largely known, and a competent model gets the middle of the distribution roughly right most of the time.
The money, however, is in the days that are not ordinary. A cold still evening with an unplanned outage can clear at twenty times the monthly average, and a windy Sunday afternoon can clear below zero. Those hours dominate the annual P&L of a retailer and the hedging cost of a large industrial consumer, and they are precisely where a model fitted to average conditions falls apart.
Building this honestly means forecasting a distribution rather than a number, and treating the tails as a separate modelling problem with their own features — reserve margin, outage notifications, interconnector availability, ramp requirements. It also means admitting where the useful horizon ends. A day-ahead forecast and a two-week outlook are different products with different error bars, and presenting them on the same axis without that distinction misleads whoever is trading against it.
Who buys this
Energy retailers, Power traders, Utility software vendors, Industrial energy managers, Flexibility aggregators
What the API returns
What comes back
- Forecast clearing price per settlement period with prediction intervals
- Spike probability — the chance of exceeding configurable price thresholds
- Negative price probability for high-renewable periods
- Expected intraday volatility and ramp magnitude by hour
- Day-ahead versus intraday spread forecasts
- Driver attribution showing which inputs moved the forecast
- Backtest accuracy by horizon, market and price band
- Forecast revision history so a changed view is auditable
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/forecast/{market} | Price forecast by settlement period for one market |
| GET | /v1/forecast/{market}/spikes | Spike and negative-price probabilities over the horizon |
| POST | /v1/forecast/scenario | Re-run the forecast under supplied weather or outage assumptions |
| GET | /v1/markets/{market}/drivers | Current driver attribution for the live forecast |
| GET | /v1/accuracy | Measured error by horizon, market and price band |
| WS | /v1/stream | Push forecast revisions and spike threshold breaches |
Request and response
illustrativeRequest
{
"market": "GB-N2EX",
"horizon_hours": 48,
"resolution": "PT30M",
"spike_thresholds_gbp_mwh": [150, 300],
"include": ["intervals", "drivers", "spikes"]
}Response
{
"market": "GB-N2EX",
"currency": "GBP",
"unit": "MWh",
"issued_at": "2026-10-22T09:05:00Z",
"periods": [
{
"start": "2026-10-23T16:30:00Z",
"p50": 118.40,
"p10": 84.10,
"p90": 212.70,
"spike_probability": { "gt_150": 0.31, "gt_300": 0.07 },
"negative_probability": 0.00
},
{
"start": "2026-10-24T12:00:00Z",
"p50": 22.60,
"p10": -4.20,
"p90": 48.90,
"spike_probability": { "gt_150": 0.01, "gt_300": 0.00 },
"negative_probability": 0.18
}
],
"drivers": [
{ "driver": "wind_forecast", "direction": "down", "weight": 0.38 },
{ "driver": "residual_demand", "direction": "up", "weight": 0.29 },
{ "driver": "plant_outages", "direction": "up", "weight": 0.21 }
],
"accuracy_note": "MAE by horizon available at /v1/accuracy; error roughly doubles beyond 72h."
}Where the data comes from
| Market operator settlement data | Published clearing prices and volumes — the authoritative history every model is fitted and scored against. Redistribution terms differ sharply by market and are checked per jurisdiction |
| Numerical weather prediction | Wind speed at hub height, solar irradiance and temperature. Open ensembles such as GFS and ICON are freely usable; higher-resolution commercial runs are licensed and usually cannot be passed through to your customers |
| Transmission operator transparency platforms | Load, generation by fuel type, interconnector flows and reserve margin, generally publishable with attribution |
| Outage notifications | Planned and unplanned generation unavailability, which is the single most useful spike feature and the most awkward to parse reliably |
| Fuel and carbon forward curves | Gas, coal and emissions prices that set the marginal cost of the price-setting plant. Almost always a paid licence with explicit no-redistribution clauses |
| Your own position and demand data | Optional. Lets the forecast be scored on the cost of being wrong for your book rather than on symmetric 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.
- Separate models for the central tendency and for the tails, because a single loss function optimised on mean error systematically underweights the hours that matter
- Quantile regression and distributional gradient boosting rather than point prediction, so the output is a price distribution per settlement period
- Weather ensemble members propagated through the model individually, giving a spread that reflects genuine meteorological uncertainty rather than a fitted residual
- Residual demand (load minus wind and solar) as the primary feature, since it tracks the merit order position far better than load alone
- Outage-driven reserve margin features with explicit handling of late and amended notifications
- Regime detection so scarcity-pricing periods are modelled apart from normal clearing conditions
- Walk-forward validation reported separately by price band — a model with good overall MAE and useless tail performance must be visible as such
- Live monitoring of calibration: if 10% of outcomes do not fall below the p10, the intervals are wrong and we would rather find out from a dashboard than from a trader
What it changes for the business
Hedging cost
Better-calibrated spike probabilities change when and how much a retailer hedges, which is where most of the avoidable cost sits.
Imbalance exposure
Intraday forecasts reduce the volume that settles at imbalance prices because positions are corrected earlier.
Product differentiation
A utility software vendor can offer price intelligence without hiring a forecasting team.
Auditable decisions
Revision history and driver attribution let a desk explain a hedge after the fact to risk committees.
How it fits into your product
How it embeds
- REST for scheduled pulls, WebSocket for revisions — most desks use both
- Forecasts delivered on the market's own settlement period grid, not a generic hourly one
- Scenario endpoint so your analysts can run their own weather or outage assumptions through the same model
- Webhooks into trading and alerting systems on spike probability thresholds
- Deployment inside your own environment where position data cannot leave
- Chart-ready output including the prediction band, for embedding in your existing 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 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 far ahead is this actually useful?
Day-ahead is where it earns its keep: errors are modest and the market is liquid enough to act on. Out to roughly 72 hours the forecast remains decision-grade. Beyond about ten days it is weather climatology with a price model attached — useful for planning ranges, not for trading. We would publish measured error by horizon so nobody has to take that on trust.
Can you predict price spikes?
We can give a calibrated probability. We cannot tell you that Thursday at 17:30 will clear at £900. Spikes depend on unit-level failures and bidding behaviour that are not observable in advance, so the honest product is a probability that is right about as often as it says it is. Any vendor promising reliable point forecasts of scarcity pricing is overselling.
Can we resell these forecasts to our own customers?
The forecasts themselves are derived output and yours to distribute. The inputs are the constraint: several fuel curve and high-resolution weather licences prohibit redistribution and in some cases restrict derived works. We map that during discovery and, where needed, build a redistributable variant on open weather and operator data with the accuracy difference measured rather than assumed.
Which markets can you cover?
Anywhere the operator publishes settlement prices, load and generation with reasonable latency — most of Europe, GB, the US ISOs, Australia. Markets with sparse or delayed publication are harder, and in a few the data simply is not there to fit a credible model. We would say so in discovery rather than take the work.
What happens when the market design changes?
It breaks the model, and pretending otherwise is how forecasting services quietly degrade. Cap changes, new balancing products and interconnector additions all shift the price formation process. We would build in regime monitoring that flags structural breaks and agree a retraining cadence up front.
Related blueprints
Energy Demand Forecasting API
Electricity and gas load forecasts by region, network segment and customer group, for utilities, retailers and network planners.
Energy Price Risk API
Volatility, spike probability and supply-demand imbalance scoring for industrial energy buyers and the software that serves them.
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.