UK electricity market data, without the archaeology
Britain publishes more market data than almost anyone, across three systems that overlap, one of which is being retired. This is a map of which source answers which question, and what bites you once you start pulling it every half hour.
Written for developers integrating GB market data. Verified against the live endpoints in September 2026.
Two organisations matter. Elexon runs settlement and publishes the balancing mechanism data through BMRS. NESO — the National Energy System Operator, formerly National Grid ESO — runs the system and publishes forecasts, carbon intensity and constraint costs.
Both give everything away through an API with no key. Britain is, for once, the easy market.
Three sources, one market
Almost every GB data question resolves to one of three publishers, and picking the wrong one is the most common time sink.
Source
What it holds
Use it for
Elexon Insights data.elexon.co.uk
Settlement and balancing: system prices, imbalance volumes, bid-offer acceptances, generation by fuel type, demand.
Anything to do with the Balancing Mechanism or imbalance settlement. This is the modern API and where new work should start.
BM Reports bmreports.com
The legacy front end over the same settlement data.
Nothing new. It still ranks and people still land there, but Insights is the supported route.
Anything about running the system rather than settling it.
BM Reports is not a second dataset. It is an older window onto the same numbers. If you are starting today, use Insights — the legacy endpoints have been progressively retired and the formats are worse.
Elexon Insights in practice
The API is open and needs no key for most datasets, which is unusual and pleasant. Responses are JSON, and the filters are consistent across endpoints once you learn the shape.
# System prices for a settlement date
GET https://data.elexon.co.uk/bmrs/api/v1/balancing/settlement/
system-prices/2026-09-15
# Generation by fuel type, half-hourly
GET https://data.elexon.co.uk/bmrs/api/v1/generation/outturn/
summary?startTime=2026-09-15T00:00Z&endTime=2026-09-16T00:00Z
Settlement periods, not hours
GB settles in half-hour periods numbered 1 to 48 per settlement day, not in clock hours. On the two clock-change days that becomes 46 and 50. Code that assumes 48 will drop or duplicate an hour twice a year — and because the data still parses, you find out months later when a reconciliation fails.
Single imbalance price
Since P305, GB uses a single imbalance price: both long and short positions settle at the same price for a given period. If you are porting logic from a dual-price market — most of continental Europe — this is the assumption most likely to be wrong in your model.
Data that only exists here
Bid-offer acceptances (BOALF) — every instruction NESO issued to every unit, with timestamps. Few markets publish balancing actions at this granularity, and it is the raw material for understanding why a system price landed where it did.
Physical notifications (PN) and MELs — what each unit said it would do and the maximum it could do, per unit, per period.
Carbon intensity — NESO publishes a forecast and outturn carbon intensity API with regional breakdown, widely used and entirely free.
Embedded generation estimates — distribution-connected solar and wind do not appear in metered generation, so NESO estimates them. If your demand numbers look wrong at midday in summer, this is why.
Traps worth knowing before you start
Settlement runs get revised. Data appears as an initial run and is recalculated through II, SF, R1, R2, R3 and RF over months. The number you pulled yesterday is not necessarily the number today. Store the run type alongside the value or your history will drift.
BMU identifiers are not tidy. A single physical plant can map to several BM units, and the mapping changes. Do not build a plant-level model on BMU IDs without a mapping table you maintain.
Times are UTC, the market thinks in local time. Settlement dates are local, timestamps are UTC, and BST shifts the boundary. Convert explicitly at the edge of your system and never in the middle.
Rate limits exist but are undocumented. Pace bulk backfills; pulling a year of half-hourly data with no delay will get you throttled without a clear error.
Where ENTSO-E fits for GB
Britain still publishes to the ENTSO-E Transparency Platform under bidding zone10YGB----------A, which is useful when you want GB in the same shape as continental zones — one parser, one schema, cross-border comparisons that line up.
But ENTSO-E carries a thin subset of what Elexon publishes, and it arrives later. For anything GB-specific — balancing actions, unit level data, settlement runs — Elexon is the source and ENTSO-E is a convenience.
For most datasets, no. The Insights API is open and returns JSON without authentication, which makes prototyping considerably faster than on markets that gate everything behind a token.
Is BM Reports still worth using?
Not for new work. It is the legacy interface over the same settlement data and endpoints have been progressively retired. Use Elexon Insights.
Why does a settlement day sometimes have 46 or 50 periods?
Because GB settles in half-hour periods and clock changes shorten or lengthen the day. Hard-coding 48 periods is the single most common bug in GB market data code.
What is the difference between Elexon and NESO data?
Elexon publishes settlement and balancing data — what was traded, instructed and paid for. NESO publishes system operation data — carbon intensity, forecasts, constraints, embedded generation estimates.
Does GB use single or dual imbalance pricing?
Single. Both long and short imbalances settle at the same price for a given settlement period, which differs from most continental markets.
We build market data integrations that survive settlement reruns, clock changes and API migrations — live feeds, dashboards and backtesting that respects publication times. If you are pulling Elexon or NESO data into something people trade on, we have done it before.