Energy & Utilities
Solar Production Forecast API
A solar portfolio produces two numbers worth money: what it will make tomorrow, and whether what it made yesterday was what it should have made. Most monitoring software answers neither.
- Solar O&M providers
- Asset managers
- Energy retailers
- Monitoring platform vendors
- Installers and EPCs
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
Solar monitoring platforms are good at showing what happened. Inverter telemetry arrives, it is charted, and a user can see yesterday's curve. What the owner actually wants to know is whether that curve was normal for the irradiance that fell on the site — because a panel string that has quietly failed looks very similar to a cloudy morning until someone compares against expectation.
On the forward side, anyone with a market position needs a generation forecast. Retailers nominate volumes, aggregators bid into balancing markets, and asset managers forecast revenue. Irradiance forecasting is a well-studied problem, but turning irradiance into AC output at a specific site requires the site's own behaviour: its orientation, its shading, its soiling rate, its inverter clipping, its temperature derating.
The two problems share one model. Fit expected production given weather for a specific asset, and you get a forecast forward and an anomaly baseline backward. The engineering difficulty is less in the physics than in the data: inverter feeds are messy, timestamps drift, meters disagree with inverters, and a site's configuration record is often wrong in ways only the production data reveals.
Who buys this
Solar O&M providers, Asset managers, Energy retailers, Monitoring platform vendors, Installers and EPCs
What the API returns
What comes back
- Expected AC production per asset at 15-minute or hourly resolution
- Prediction intervals reflecting both weather and model uncertainty
- Nowcast for the next few hours from satellite cloud motion
- Performance ratio against weather-adjusted expectation
- Underperformance anomalies with probable cause classification
- Soiling and degradation trend estimates per asset
- Clipping and curtailment attribution, separated from genuine faults
- Portfolio aggregation with correlated uncertainty rather than naive summation
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/assets/{id}/forecast | Production forecast for one asset |
| GET | /v1/assets/{id}/nowcast | Short-horizon forecast from satellite cloud motion |
| POST | /v1/portfolio/forecast | Aggregated forecast across a set of assets |
| GET | /v1/assets/{id}/performance | Weather-adjusted performance ratio and trend |
| GET | /v1/anomalies | Open underperformance anomalies across the portfolio |
| POST | /v1/assets | Register or update asset configuration and telemetry mapping |
Request and response
illustrativeRequest
{
"asset_id": "site_00412",
"horizon_hours": 72,
"resolution": "PT15M",
"include": ["intervals", "clipping", "nowcast"]
}Response
{
"asset_id": "site_00412",
"capacity_kwp": 4820,
"issued_at": "2026-10-22T06:00:00Z",
"forecast": [
{ "start": "2026-10-22T11:00:00Z", "p50_kwh": 982.4, "p10_kwh": 611.0,
"p90_kwh": 1140.2, "clipping_expected_kwh": 0.0 },
{ "start": "2026-10-23T11:00:00Z", "p50_kwh": 1204.8, "p10_kwh": 1088.3,
"p90_kwh": 1241.0, "clipping_expected_kwh": 38.6 }
],
"day_totals_kwh": { "2026-10-22": 14820, "2026-10-23": 19340, "2026-10-24": 9110 },
"performance": {
"performance_ratio_30d": 0.781,
"expected_ratio_30d": 0.822,
"soiling_loss_estimate": 0.021,
"degradation_pct_per_year": 0.54
},
"anomalies": [
{ "detected_on": "2026-10-14", "severity": "medium",
"deficit_pct": 6.1, "probable_cause": "string_offline",
"evidence": "Deficit constant across irradiance levels, confined to inverter 3" }
]
}Where the data comes from
| Satellite-derived irradiance | Geostationary cloud imagery converted to surface irradiance — the backbone of nowcasting. Some products are open with attribution, others are licensed per site and cannot be redistributed |
| Numerical weather prediction | Multi-day irradiance, temperature and wind for the day-ahead horizon. Open global ensembles are usable commercially; high-resolution regional runs usually are not |
| Your inverter and meter telemetry | Per-inverter AC output, DC strings where available, and revenue meter readings. This is what the site-specific model is fitted on |
| Asset configuration records | Tilt, azimuth, module and inverter specifications, string layout. Frequently wrong in the as-built records, so we validate it against production |
| On-site sensors where present | Pyranometers and module temperature sensors, which materially tighten the performance baseline when they are calibrated |
| Operator curtailment signals | So network-instructed reductions are not logged as equipment faults |
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.
- A physical plane-of-array and temperature model as the backbone, with a learned residual correction per asset — pure machine learning needs more site history than most assets have, and pure physics never captures local shading
- Satellite cloud motion vectors for the zero-to-four-hour horizon, handing over to NWP beyond that, with a blended transition rather than a hard switch
- Ensemble propagation so the forecast interval widens genuinely on uncertain cloud days instead of applying a fixed percentage band
- Clipping modelled explicitly from the DC/AC ratio, since clipped hours are truncated and will otherwise bias the fitted response curve
- Anomaly detection on the residual between observed and weather-adjusted expectation, with cause classification from the residual's shape across irradiance levels and its distribution across inverters
- Soiling and degradation separated by timescale — soiling recovers after rain or cleaning, degradation does not
- Portfolio aggregation using a spatial correlation structure, because summing independent intervals understates portfolio certainty badly
- Validation on held-out days reported per asset, with telemetry gap and sensor drift monitoring on the input side
What it changes for the business
Fault detection speed
Weather-adjusted baselines surface a failed string in days rather than at the next site visit.
Nomination accuracy
Tighter generation forecasts reduce the volume a retailer or aggregator settles at imbalance prices.
Warranty and performance claims
Documented weather-adjusted shortfall is the evidence that makes a performance guarantee claim stick.
Monitoring product upgrade
A monitoring vendor gains forecasting and diagnostics without building a weather stack.
How it fits into your product
How it embeds
- Asset registration endpoint so new sites start forecasting without a manual onboarding project
- Telemetry ingested by push, by pull from your existing data store, or from common inverter cloud APIs
- Portfolio endpoints shaped for trading nomination deadlines, not just for dashboards
- Webhooks on new anomalies into your ticketing or field service system
- White-label output for monitoring platforms reselling to asset owners
- Chart-ready forecast bands and expectation-versus-actual series for embedding
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 much site history do you need before the forecast is good?
A few clear days gets a usable physical model. Three to six months, covering a range of sun angles and weather, is where the learned correction starts paying for itself, and a full year is needed before shading and seasonal soiling patterns are properly characterised. For a brand-new site we would return a physics-only forecast with wider intervals and say plainly that it is the less accurate variant.
What is the realistic forecast horizon?
Nowcasting out to four hours is sharply better than NWP because cloud motion is observable. Day-ahead is reliable enough to nominate against. Day three is noticeably worse, and beyond about a week the useful output is a monthly energy range rather than an hourly curve. We would rather label that boundary than let a user trade against day-nine numbers.
Can it tell us exactly what is broken?
It classifies probable cause from the signature of the deficit — a constant proportional loss looks like soiling, a fixed absolute loss confined to one inverter looks like an offline string, a loss that only appears at high irradiance suggests a thermal or clipping issue. It narrows the field for a technician. It is not a substitute for a site visit and we would not present a classification as a diagnosis.
Do you need our raw telemetry in your systems?
For a hosted service, yes, at least the per-inverter time series. Where that is unacceptable we deploy inside your own environment and the model trains next to your data. Several asset managers choose that route for contractual reasons with their owners, and it is a supported configuration rather than an exception.
Can we pass the irradiance data through to our customers?
Not always, and this catches people out. Some satellite irradiance products permit derived output only, not the underlying values, and a few restrict even per-site redistribution. Your forecasts are yours. Re-serving licensed irradiance as a data field is a different act with a different licence, and we design the response schema around whichever constraint applies.
Related blueprints
Renewable Generation Forecast API
Wind and hydro output forecasts at asset, zone and system level for grid operations, nomination and trading desks.
Grid Congestion Intelligence API
Network constraint forecasts, curtailment risk and locational signals for developers, traders and flexibility operators.
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.