Energy & Utilities
Grid Congestion Intelligence API
Where you connect an asset now matters more than what you build. Congestion decides which megawatt hours get paid and which get curtailed.
- Renewable developers
- Flexibility and storage operators
- Power traders
- Network planning consultancies
- EV charging operators
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
Transmission and distribution networks were built for a generation fleet that no longer exists. Wind sits where the wind is, which is rarely where the demand or the existing network capacity is, and the result is persistent constraint: generation that is instructed down, connection queues measured in years, and locational price differences that in some markets exceed the energy price itself.
For anyone siting an asset this is the dominant commercial variable. A battery at a constrained node and the same battery thirty kilometres away have materially different revenue. A solar farm in a region with a twenty percent curtailment rate has a different business case from the identical one in an unconstrained zone, and the difference will not show in an irradiance study.
The information needed to see this is largely public and almost unusable in its published form. Operators publish constraint boundaries, curtailment instructions, connection registers and network development plans across dozens of inconsistent documents and portals, in formats that change without notice. Assembling that into a locational view is unglamorous data engineering, and it is the whole product.
Who buys this
Renewable developers, Flexibility and storage operators, Power traders, Network planning consultancies, EV charging operators
What the API returns
What comes back
- Constraint forecasts by boundary and node over short and seasonal horizons
- Curtailment risk estimates per location and technology
- Historical curtailment volumes and compensation by zone
- Locational price spread forecasts where the market is nodal or zonal
- Connection queue position and capacity headroom by substation
- Network reinforcement timelines from published development plans
- Flexibility service opportunity by location and product
- Change alerts when a published constraint or queue position moves
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/locations/{id}/congestion | Constraint and curtailment outlook for one location |
| POST | /v1/siting/score | Score candidate sites on congestion and curtailment risk |
| GET | /v1/boundaries/{boundary}/forecast | Constraint forecast for a network boundary |
| GET | /v1/substations/{id}/headroom | Available capacity and queue position |
| GET | /v1/curtailment/history | Historical curtailment volumes by zone and technology |
| WS | /v1/stream | Push constraint events and queue or plan changes |
Request and response
illustrativeRequest
{
"candidate_sites": [
{ "label": "Fenwick Moor", "lat": 55.72, "lon": -4.39, "technology": "bess", "capacity_mw": 50 },
{ "label": "Hartmoor East", "lat": 54.11, "lon": -1.52, "technology": "solar", "capacity_mw": 35 }
],
"horizon": "seasonal",
"include": ["curtailment_risk", "headroom", "reinforcement"]
}Response
{
"issued_at": "2026-10-22T08:00:00Z",
"sites": [
{
"label": "Fenwick Moor",
"zone": "SCOT-CENTRAL",
"congestion_score": 81,
"band": "high",
"curtailment_risk": {
"expected_annual_pct": 14.2,
"p90_annual_pct": 23.8,
"driver": "B6_boundary_export_limit"
},
"substation": { "name": "Fenwick 132kV", "headroom_mw": 12.0, "queue_position": 7,
"earliest_energisation": "2029-Q3" },
"reinforcement": { "scheme": "East Coast 400kV upgrade", "published_completion": "2031" },
"flexibility_opportunity": ["export_constraint_management", "local_dno_flex"]
},
{
"label": "Hartmoor East",
"zone": "ENG-NE",
"congestion_score": 34,
"band": "moderate",
"curtailment_risk": { "expected_annual_pct": 3.1, "p90_annual_pct": 6.4,
"driver": "local_33kV_thermal" }
}
],
"data_note": "Queue positions reflect the operator register as published; registers lag real decisions."
}Where the data comes from
| Transmission operator constraint data | Published boundary limits, constraint costs and balancing instructions. Generally open with attribution, though formats and publication cadence vary by operator |
| Curtailment and bid-offer acceptance records | Which units were instructed down, when and at what cost — the ground truth every curtailment estimate is validated against |
| Connection registers and queue data | Published by transmission and distribution operators at differing levels of detail. Known to lag actual decisions, which we surface rather than smooth over |
| Network development plans | Operator ten-year statements and reinforcement schemes, which set when a constraint is expected to ease. Published dates slip and we track revisions rather than the latest figure alone |
| Generation and demand registers by location | Connected and contracted capacity by substation, needed to estimate headroom |
| Weather and generation forecasts | Constraints bind when renewable output is high and local demand is low, so the short-horizon forecast depends on the same weather inputs as generation forecasting |
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.
- Boundary flow modelling from published limits, connected capacity and forecast generation, rather than a full power flow — which would need network data operators do not publish
- Curtailment probability estimated from historical instruction records conditioned on boundary flow, technology and time of year
- Locational scoring that combines current binding constraints with the expected trajectory as reinforcement schemes complete or slip
- Document and portal ingestion built for change: operator publication formats shift regularly, so parsers are versioned and failures alert rather than silently return stale data
- Queue data treated as a lagging indicator with explicit staleness reporting, because the register and the real position routinely differ
- Seasonal and short-horizon models kept separate — next-week constraint risk is a weather question, next-decade constraint risk is a capital plan question
- Backtesting of curtailment estimates against realised curtailment by zone, reported per technology
- Monitoring for structural change: a new interconnector or reinforcement completing invalidates historical constraint relationships at that boundary
What it changes for the business
Siting decisions
Curtailment risk at candidate sites changes site ranking before land and grid costs are committed.
Revenue modelling
Expected curtailment percentages feed directly into the financial model a lender will scrutinise.
Flexibility revenue
Constrained locations are where local flexibility products are worth most, and finding them is the hard part.
Due diligence speed
A locational screen in minutes replaces weeks of consultancy work across operator portals.
How it fits into your product
How it embeds
- Siting endpoint accepting coordinate lists, so a whole development pipeline can be screened in one call
- Geospatial output your GIS or mapping layer can render directly
- Webhooks on queue position changes and newly binding constraints
- Scheduled reports for investment committee and lender packs
- White-label delivery for consultancies and developers presenting to clients
- Per-market configuration, since constraint mechanisms differ substantially between jurisdictions
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 reliable is connection queue data?
Less reliable than it looks. Operator registers are published periodically and lag actual decisions, offers and withdrawals, sometimes by months. We return the register as published with an explicit staleness timestamp rather than presenting it as current truth. For a specific site at a specific decision point, the register is a screening tool and a direct operator enquiry is still necessary.
Can you forecast curtailment years ahead?
We can give a range conditioned on published reinforcement timelines, and those timelines slip. A scheme listed for 2031 may complete in 2034, which changes a curtailment estimate materially. We track the revision history of published dates so you can see how often a given scheme has moved, which is more useful than quoting the current date with confidence.
Is this a power flow model?
No, and it would be dishonest to imply otherwise. Full power flow needs detailed network topology and impedance data that operators do not publish. We model at boundary and substation level from published limits, flows and instruction records. That is enough for siting and curtailment risk; it is not enough to tell you a line loading to the ampere.
Can we redistribute this to our clients?
Mostly yes, with care. Operator transparency data generally permits reuse with attribution, and our derived scores are yours. A few national datasets carry commercial restrictions, and some market data used for locational spreads is licensed with no-redistribution clauses. We identify each source's terms in discovery and build the redistributable variant explicitly where that matters to your business model.
Which markets does this work in?
Best where the operator publishes constraint and instruction data well — GB, most of the EU, the US ISOs with nodal pricing, Australia. In markets where constraint management is opaque or curtailment is not published per unit, the honest answer is that the historical ground truth is missing and we cannot validate an estimate. We would decline rather than ship an unvalidated model.
Related blueprints
Renewable Generation Forecast API
Wind and hydro output forecasts at asset, zone and system level for grid operations, nomination and trading desks.
Electricity Price Forecasting API
Wholesale electricity price forecasts and spike alerts by market and delivery hour, embedded in energy trading and retail 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.