# Use with an agent (https://grid.rebase.energy/docs/v1/guides/agents/)
An agent needs one thing: one of the files below. No API key is required
([Use without a key](https://grid.rebase.energy/docs/v1/guides/open-access/)): an agent can fetch prices, load, generation, forecasts
and flows straight away at 30 requests per minute, with nothing to ask its user for. For a job that
needs more, give it a free key, which raises the limit to 240 per minute
([Get a key](https://grid.rebase.energy/docs/v1/guides/authentication/#get-a-key)).
## What to give the agent [#what-to-give-the-agent]
Three machine-readable entry points are published with these docs:
| File | Contents |
| ------------------------------------------------------------ | ------------------------------------------------------------------ |
| [`grid.rebase.energy/docs/v1/llms.txt`](https://grid.rebase.energy/docs/v1/llms.txt) | the calling rules below, then an index of every page of these docs |
| [`grid.rebase.energy/docs/v1/llms-full.txt`](https://grid.rebase.energy/docs/v1/llms-full.txt) | every page of these docs as one Markdown file, this one included |
| [`grid.rebase.energy/docs/v1/openapi.json`](https://grid.rebase.energy/docs/v1/openapi.json) | the endpoint contract, with example responses |
Every page is also available as Markdown from the **Copy Markdown** button at its top.
The entity tree gives an agent the ids and how they nest, each response carries the path of the
next call (`metadata`, `values`, `list`), and once the entities are known search finds a series in
one request, so an agent with one of these files can collect a dataset on its own. Example prompt:
> *Using the Rebase Grid API (docs at grid.rebase.energy/docs/v1/llms-full.txt, no key needed),
> save France's production by type for the last 30 days as one CSV, one column per type at the
> native resolution, and plot the daily averages as a stacked bar chart.*
With a key, add "key in `X-API-Key`" to the prompt.
## Calling rules [#calling-rules]
These rules follow from how the endpoints are built. They hold for a script as much as for an
agent: following them, a job makes few requests, stays under the rate limit and avoids errors.
### Requests [#requests]
* **No key is needed.** Every endpoint answers a request without an API key, at **30 requests per
minute per IP address** (up to 30 at once, refilled at one every 2 seconds). See
[Use without a key](https://grid.rebase.energy/docs/v1/guides/open-access/).
* **240 requests per minute per key**, as a token bucket: up to 240 in a burst, refilled at 4 per
second. A key is free: [Get a key](https://grid.rebase.energy/docs/v1/guides/authentication/#get-a-key).
* **Read several timeseries in one request.**
[`POST /timeseries/values`](https://grid.rebase.energy/docs/v1/reference/read/many-values/) returns the latest values of up to
2,000 timeseries (5 without a key) over one shared window, and counts as one request. Use it
instead of one values call per timeseries: see [Reading many timeseries](#reading-many-timeseries).
* **Retry 429 and 503 after `Retry-After`.** A 400 or a 404 fails the same way when repeated: read
its `message`, and `param` (the offending parameter, on a 400) or `closest` (the nearest ids or
names, on a 404).
* **`next` has two forms.** On search, values snapshots and the many-series call, `next` is a
value: send the same request again with `cursor` set to it. On the lists under an entity
(`plants`, `units`, `portfolios`), `next` is the path and query of the next page: request it as
it is, and do not pass it as `cursor`. In both, `null` means the last page.
### Finding timeseries [#finding-timeseries]
* **Walk the tree first.** At the start the entity ids, their kinds and their parents are unknown,
and search needs them. Three calls give the full context:
1. [`GET /entities`](https://grid.rebase.energy/docs/v1/reference/discover/entity-tree/): the whole tree;
2. [`GET /entities/{entity}`](https://grid.rebase.energy/docs/v1/reference/discover/entity/): one entity with its parent, children
and relations;
3. [`GET /entities/{entity}/timeseries`](https://grid.rebase.energy/docs/v1/reference/discover/timeseries-names/): the names on it,
with their providers.
* **Then search.** Once the entities and the naming are known,
[`GET /timeseries`](https://grid.rebase.energy/docs/v1/reference/discover/search/) with `entity` and `q` (or `category`,
`data_type`) finds further timeseries in one call each. Pages hold up to 1,000 items
(`limit=1000`).
* **Take ids from the API; do not compose them.** A country is its English name (`Sweden`,
`Germany-Luxembourg`), a price zone its code (`SE-SE3`, `IT-NO`, `SEM`, `GB`), and every other
kind carries a prefix (`border:FI~SE-SE3`, `plant:46WPU0000000015W`, `unit:46WGU0000000137O`). ISO country codes (`IT`,
`IE`), guessed zone names (`IT-NORD`, `IE-SEM`) and bare EIC codes are not ids. A wrong id is a
404 whose `closest` lists the nearest real ones.
* **A border id is its two zone ids in alphabetical order**, joined by `~`: `border:FR~GB`, not
`border:GB~FR`. Only pairs with a market link exist: read the borders of a zone from `relations` in
[`GET /entities/{entity}`](https://grid.rebase.energy/docs/v1/reference/discover/entity/). Its `positive` field gives the direction
of a positive flow. A border series is not on every border: day-ahead NTC
(`exchange_capacity.ntc_atc.day_ahead_ntc`) exists only where capacity is allocated border by
border, not on the flow-based borders of central western Europe (`border:BE~FR`,
`border:DE-LU~FR`).
* **Names differ per entity and per provider.** A name read on one entity, such as a capacity
series on one border, need not exist on the next one, and a provider that publishes it for one
zone may not for another. List `GET /entities/{entity}/timeseries` for each entity before
building values URLs. A 404 on a values call means the name is not on that entity; an empty
window is a `200` with no points.
* **Ids and names do not change**, so the tree and the list of timeseries a job uses can be kept
and reused instead of read again on every run.
### Metadata [#metadata]
* **Read the metadata once per timeseries.** Latency, coverage and annotations are computed over
the last seven days (the last 20,000 intervals of a series finer than one minute) and kept for
24 hours, so reading them more often returns the same numbers.
Its `resolution` sets the window size (next section).
### Reading values [#reading-values]
* **`provider`, `start` and `end` are required** on every values call. `provider` is required
also when only one exists (a 400 without it lists the ones to choose from, in `providers`);
`start` and `end` are UTC timestamps (`2026-11-09T00:00:00Z`), both inclusive. The query
separator is a plain `&`: a URL copied from HTML with `&` loses every parameter after the
first.
* **Read `resolution` from the metadata, then use the largest window that fits.** A values call
may span at most 100,000 points at the series' resolution: 11 years at `PT1H`, about 1,041 days
at `PT15M`, 69 days at `PT1M`, under 5 days at `PT4S` and under 28 hours at `PT1S`. aFRR
activation prices (`PT4S`) and grid frequency are that fine, so a 30-day window that works for a
day-ahead price is a `400` for them. A series without a fixed resolution (`resolution: null`:
outages published as change-points, installed capacity) may span at most 366 days. A longer
range is split into consecutive windows; a larger window is `400` (`param: end`) before any
data is read.
* **Poll by publication latency, not by the clock.** `latency_minutes` says when a provider's value
for an interval usually arrives (p50) and nearly always has (p95). A live job that runs after the
p95 finds its data in one call.
* **Re-read a trailing window to catch revisions.** Values are selected by `valid_time`; a
correction to an interval read earlier arrives as a new version of that interval, not as a new
interval. An incremental job re-reads the last day or so with each run, not only the newest
intervals.
### Reading many timeseries [#reading-many-timeseries]
* **One many-series call instead of N values calls.** When a job needs the same window from
several timeseries, [`POST /timeseries/values`](https://grid.rebase.energy/docs/v1/guides/many-values/) takes them as a list of
`{entity, name, provider}` in a JSON body, with one `start` and `end` for all. Up to 2,000
timeseries per call with a key, 5 without.
* **Follow `next`.** A page holds whole series up to 200,000 points in total. When `next` is not
`null`, send the same body again with `cursor` set to it.
* **Check each block.** A series that cannot be read does not fail the call: its block carries
`error` in place of `points`, and the call is still `200`.
* **Latest version only.** For values as known at an earlier time (`as_of`), use the one-series
[values call](https://grid.rebase.energy/docs/v1/guides/values/). Metadata is also one call per timeseries.
### Reading many versions [#reading-many-versions]
* **`as_of` takes three forms**: an instant (`2026-11-09T10:00:00Z`: the data as known then), a
period (`P1D`, `PT1H`: one snapshot per period) or `rolling`. Nothing else is accepted.
* **One snapshot call instead of many instant calls.** To see the data as it was at N instants, one
call with `as_of` set to their period (`P1D&at=10:00`, `PT1H`) returns all N snapshots; N calls
with `as_of` set to each instant return the same data.
* **Snapshot pages hold up to 1,000 snapshots** (`max_snapshots=1000`; the default is 100).
Each page reads the whole window again, so fewer, larger pages mean fewer calls. Follow `next`,
passed back as `cursor`, until it is `null`.
* **A request may produce at most 10,000 snapshots, and each repeats the window**, so keep the
window short or the period long; more is `400` (`param: as_of`).
# Authentication (https://grid.rebase.energy/docs/v1/guides/authentication/)
A key is optional. Without one every endpoint still answers, at 30 requests per minute per IP
address ([Use without a key](https://grid.rebase.energy/docs/v1/guides/open-access/)). A key is free and raises the limit to 240
requests per minute.
## Get a key [#get-a-key]
To get a key:
1. Request one with the [key request form](https://app.notion.com/p/rebase-energy/3798f95cc39b802f8672eb93c6ab77c5?pvs=106).
2. An email brings your personal link to the [grid map](https://grid.rebase.energy).
3. Open the link. The key is shown on the welcome card, and at any time in the **API** tab of the
map's right panel.
The same key works for every endpoint of this API. Keep it secret: it identifies you, and the
[rate limit](https://grid.rebase.energy/docs/v1/guides/limits/) counts per key. `GET /me` returns the owner of a key, which confirms
the key works before you script anything.
## Send the key [#send-the-key]
Send the key in the `X-API-Key` header, or as the `api_key` query parameter.
The examples in these guides use this setup:
```bash
export KEY=""
export API="https://grid.rebase.energy/api/v1"
```
```python
import requests
API = "https://grid.rebase.energy/api/v1"
HEADERS = {"X-API-Key": ""}
```
A request with a key that is not valid returns `401 unauthorized`; a request with no key at all
is answered under the [open limit](https://grid.rebase.energy/docs/v1/guides/open-access/) (`GET /me` alone needs a key). Each key
may make 240 requests per minute; see [Limits](https://grid.rebase.energy/docs/v1/guides/limits/).
To try a call from the [API Reference](https://grid.rebase.energy/docs/v1/reference/), enter the key in the playground of the
endpoint.
# Entities (https://grid.rebase.energy/docs/v1/guides/entities/)
An entity is an object that holds timeseries. Entities form a tree: each one has at most one
parent and any number of children, of the kinds listed below. Relations connect two entities and
are listed on both.
| Entity | Example id | Represents | Parents | Children |
| ---------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------ |
| `sync_area` | `sync:NSA` | a synchronous area: the grids that share one frequency. Every entity carries it as a tag rather than a parent | — | — |
| `country` | `Sweden` | a state; holds the data published for the whole country | — | `price_zone` |
| `price_zone` | `SE-SE3` | a bidding zone of the electricity market | `country`, or none when a zone spans several states (`SEM`, `GB`) | `area`, `boundary`, `substation`, `plant`, `portfolio` |
| `area` | `ca:DE-50Hertz` | a part of a zone or of another area: a control area, the national part of a multi-country zone, a region, an island system, or a GB grid supply point group | `price_zone`, `area` | `area`, `substation`, `plant`, `portfolio` |
| `aggregate` | `NORDICS` | a named set of zones that owns the data published for the whole, such as the Nordic system price | — | — |
| `boundary` | `bnd:GB-B6` | a transmission boundary inside a zone, with its flow and limit | `price_zone` | — |
| `substation` | `sub:Revsing` | a grid node, the end of an interconnector | `price_zone`, `area` | — |
| `plant` | `plant:46WPU0000000015W` | a power plant at one location; holds the plant-level data (installed capacity, outages). Its `portfolio` field names the portfolio it belongs to, if any | `price_zone`, `area` | `unit` |
| `unit` | `unit:46WGU0000000137O` | one generation, storage or demand unit; holds the unit-level data (actual output) | `plant` | — |
| `portfolio` | `portfolio:bmu-2__AANGE001` | a group of plants that a market registers and settles as one: an ENTSO-E production unit that covers several plants (a hydro cascade, a cluster of wind farms, an aggregator), or an Elexon BM unit for a supplier's base demand (`2__`) or a virtual lead party (`V__`). It has no location of its own; its plants name it in their `portfolio` field, and the portfolio call lists them under `plants` | `price_zone`, `area` | — |
| `border` | `border:FI~SE-SE3` | a **relation**: the market link between two price zones; holds the flows, schedules and capacities between them | the two price zones | `interconnector` |
| `interconnector` | `icx:BritNed` | a **relation**: a cable between two substations, and the border it sits on | the two substations | — |
Every id is accepted wherever an entity is expected. An unknown id returns 404 with the three
closest ids. Ids are read from the API, not composed: a country is its English name
(`Germany-Luxembourg`, not `Germany` or `DE`), a price zone its code (`IT-NO`, not `IT-NORD`), and
ISO country codes and bare EIC codes are not ids. A border id is its two zone ids in alphabetical
order joined by `~` (`border:FR~GB`, not `border:GB~FR`), and only the pairs listed in a zone's
`relations` exist. Timeseries names differ per entity and per provider: a name found on one border
or zone need not exist on another, so list each entity's names
([Timeseries names](https://grid.rebase.energy/docs/v1/guides/timeseries-names/)) before reading values. Plants, units and portfolios are also reachable by name after the kind prefix; see
[Plants, units and portfolios](https://grid.rebase.energy/docs/v1/guides/plants/).
## The tree [#the-tree]
[`GET /entities`](https://grid.rebase.energy/docs/v1/reference/discover/entity-tree/) returns the whole tree, nested, with the number
of timeseries on each entity; plants, units and portfolios stay out of it and appear as one summary
line per kind on their zone. [`GET /entities/{entity}`](https://grid.rebase.energy/docs/v1/reference/discover/entity/) returns one
entity with its parent, country, synchronous area, children and relations.
# Errors (https://grid.rebase.energy/docs/v1/guides/errors/)
Errors return `{"error": ..., "message": ...}`:
| `error` | Status | Also carries |
| --------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `unauthorized` | 401 | |
| `bad_request` | 400 | `param`, the offending parameter; `providers` when the provider is missing or unknown |
| `not_found` | 404 | `closest`, the three closest ids or names. With `reason: index_stale` and an empty `closest`, the name is listed but the series behind it is gone: the list is behind, and retrying does not help |
| `rate_limited` | 429 | `Retry-After` header; [without a key](https://grid.rebase.energy/docs/v1/guides/open-access/) also `anonymous`, `limit_rpm`, `key_limit_rpm`, `retry_after_s`, `sign_up`, `docs` and `info` |
| `platform_unavailable`, `index_warming` | 503 | `Retry-After` header |
| `not_implemented` | 501 | |
A 400 and a 404 fail the same way when repeated; a 429 and a 503 succeed after the `Retry-After`.
A 404 on a values call means the timeseries name is not on that entity (names differ per entity
and per provider); a window with no data is a `200` with no points.
# Plot every version of a forecast (https://grid.rebase.energy/docs/v1/guides/forecast-versions/)
A forecast is published, then revised. The API keeps every version, so one call returns the
forecast as it stood at each hour, and the versions can be drawn on top of each other.
This example reads Fingrid's day-ahead load forecast for Finland, as published on the ENTSO-E
Transparency Platform, for yesterday:
**Read one snapshot per hour.** `as_of=PT1H` returns the whole window as it was known at every
hour. The window starts two days before the delivery day, so it also covers the hours when the
forecast was issued and revised.
**Keep the versions.** From each snapshot keep the delivery day, and drop the snapshots that did
not change it: what remains are the versions of the forecast.
**Plot them**, coloured from the oldest to the newest.
```python
import os
from datetime import datetime, timedelta, timezone
import matplotlib.pyplot as plt
import pandas as pd
import requests
API = "https://grid.rebase.energy/api/v1"
HEADERS = {"X-API-Key": os.environ["GRID_API_KEY"]}
ENTITY = "FI"
NAME = "consumption.load_forecast.day_ahead_total_load_forecast"
# The delivery day is yesterday. The window starts two days earlier, so the snapshots also
# cover the hours before the delivery day, when the forecast was issued and revised.
day = datetime.now(timezone.utc).replace(hour=0, minute=0, second=0, microsecond=0) - timedelta(days=1)
start, end = day - timedelta(days=2), day + timedelta(days=1)
# One snapshot per hour: each is the whole window as it was known at that hour.
r = requests.get(
f"{API}/entities/{ENTITY}/timeseries/{NAME}/values",
headers=HEADERS,
params={
"provider": "entsoe",
"start": start.isoformat(),
"end": end.isoformat(),
"as_of": "PT1H",
"max_snapshots": 1000,
},
)
r.raise_for_status()
# Keep the delivery day from each snapshot, and only the snapshots that changed it: those are
# the versions of the forecast.
versions = []
for snapshot in r.json()["snapshots"]:
points = pd.DataFrame(snapshot["points"])
points["valid_time"] = pd.to_datetime(points["valid_time"])
points = points[(points["valid_time"] >= day) & (points["valid_time"] < day + timedelta(days=1))]
if points.empty:
continue
series = points.set_index("valid_time")["value"]
if versions and series.equals(versions[-1][1]):
continue
versions.append((snapshot["as_of"], series))
fig, ax = plt.subplots(figsize=(10, 5))
colors = plt.cm.viridis([i / max(len(versions) - 1, 1) for i in range(len(versions))])
for (as_of, series), color in zip(versions, colors):
ax.plot(series.index, series.values, color=color, linewidth=1.2, label=f"as of {as_of[5:16]}")
ax.set_title(f"{ENTITY} day-ahead load forecast for {day:%Y-%m-%d}: {len(versions)} versions")
ax.set_ylabel("MW")
ax.legend(fontsize=7, ncol=2)
fig.tight_layout()
plt.show()
```
Version history starts when the collection of a series starts, so the earliest delivery day with
versions is 3 September 2026. For the snapshot forms of `as_of`, see
[Reading values](https://grid.rebase.energy/docs/v1/guides/values/).
The script is [`docs-site/examples/forecast_versions.py`](https://github.com/rebase-energy/rebase-grid/blob/main/docs-site/examples/forecast_versions.py);
it needs `requests`, `pandas` and `matplotlib`, and the key in `GRID_API_KEY`.
# Introduction (https://grid.rebase.energy/docs/v1/guides/introduction/)
The Grid API is a REST API for European power system data: production, consumption, prices,
exchanges, capacities and balancing, collected from TSOs, exchanges and transparency platforms.
No API key is needed: every endpoint answers without one, at 30 requests per minute
([Use without a key](https://grid.rebase.energy/docs/v1/guides/open-access/)). A free key raises the limit to 240 per minute;
[Authentication](https://grid.rebase.energy/docs/v1/guides/authentication/#get-a-key) says how to get one.
## Two resources [#two-resources]
**Entities** are the places that hold data: synchronous areas, countries, price zones, borders,
interconnectors, substations, plants, units and portfolios, arranged as a tree. See
[Entities](https://grid.rebase.energy/docs/v1/guides/entities/).
**Timeseries** are the data on an entity, identified by a name
(`category.sub_category.definition[.component]`) and a provider, the organisation that published
it. See [Timeseries names](https://grid.rebase.energy/docs/v1/guides/timeseries-names/).
## Three steps [#three-steps]
Every use of the API is the same three steps:
**Discover** an entity and the names of the timeseries on it, by walking the tree or by
[search](https://grid.rebase.energy/docs/v1/guides/search/).
**Describe** a timeseries: its definition, and for each provider its resolution, extent,
publication latency and coverage. See [Metadata](https://grid.rebase.energy/docs/v1/guides/metadata/).
**Read** its values for a time range. See [Reading values](https://grid.rebase.energy/docs/v1/guides/values/).
## How values are stored [#how-values-are-stored]
Values are stored as published by the provider and are not filled, smoothed or estimated. Every
value carries the time it became known (`knowledge_time`), and a value that is published again is
kept as a new version. The `as_of` parameter on the values call selects which version is returned:
the latest, the one known at an instant, or a series of snapshots showing how it changed. Where a provider
fills a gap itself, the point says so in its `annotation`.
Notes on scope:
* Version history starts when the collection of a series starts (the earliest is 3 September
2026\). Values before that are backfilled and have a single version.
* `publication_time` in the metadata says whether `knowledge_time` is `declared` by the provider or
`measured` as the time the value was observed to appear.
* Clean series built by Rebase are published under the provider `rebase`, with their inputs and
method in the metadata.
# Limits (https://grid.rebase.energy/docs/v1/guides/limits/)
| Limit | Value | When exceeded |
| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| Requests per API key | 240 per minute | `429 rate_limited`, with `Retry-After` |
| Requests [without a key](https://grid.rebase.energy/docs/v1/guides/open-access/) | 30 per minute per IP address | `429 rate_limited`, with `Retry-After` and where to get a key |
| Points per values request | 100,000 at the series' resolution: 11 years at `PT1H`, 1,041 days at `PT15M`, under 28 hours at `PT1S` | `400 bad_request` (`param: end`); split the window |
| Series per [many-series call](https://grid.rebase.energy/docs/v1/guides/many-values/) | 2,000 (5 without a key); a page holds whole series up to 200,000 points | `400 bad_request` over 2,000; series past a full page come with `next` |
| Time range for a series without a regular step (e.g. outages published as change-points, installed capacity) | 366 days, since the point count cannot be computed | `400 bad_request` (`param: end`) |
| Search results per page | 100 by default, `limit` up to 1,000 | the rest pages with `next` |
| Snapshots per page | 100 by default, `max_snapshots` up to 1,000 | the rest pages with `next` |
All times are UTC, in ISO 8601. How to stay inside these limits with few requests:
[Calling rules](https://grid.rebase.energy/docs/v1/guides/agents/#calling-rules).
# Reading many timeseries (https://grid.rebase.energy/docs/v1/guides/many-values/)
[`POST /timeseries/values`](https://grid.rebase.energy/docs/v1/reference/read/many-values/) returns the latest values of up to
**2,000 timeseries** over one shared time range, in one call. Use it when you need the same window
from many entities, such as the schedules of every plant in a zone, instead of one
[values call](https://grid.rebase.energy/docs/v1/guides/values/) per timeseries.
The timeseries are listed in a JSON body, so the list can be long. The call only reads: it is a
POST because a request body has no length limit, where a URL does.
## Request [#request]
| Body field | Meaning |
| -------------- | --------------------------------------------------------------------------------------------------- |
| `series` | a list of `{entity, name, provider}`, 1 to 2,000 items: the same three things one values call names |
| `start`, `end` | the time range, shared by every series; both inclusive |
| `cursor` | the `next` of the previous page; send the rest of the body unchanged |
```bash
curl -X POST "$API/timeseries/values" -H "X-API-Key: $KEY" -H "Content-Type: application/json" -d '{
"start": "2026-11-03T12:00:00Z",
"end": "2026-11-03T13:00:00Z",
"series": [
{"entity": "plant:18W000000000AI3J", "name": "production.per_unit.esios_p48_final_programme_injection", "provider": "esios"},
{"entity": "plant:18W000000000F3DO", "name": "production.per_unit.esios_p48_final_programme_injection", "provider": "esios"},
{"entity": "unit:18W000000000AI2L", "name": "production.per_unit.actual_generation_per_unit_a73.18w000000000ai2l", "provider": "entsoe"}
]
}'
```
```python
P48 = "production.per_unit.esios_p48_final_programme_injection"
body = {
"start": "2026-11-03T12:00:00Z",
"end": "2026-11-03T13:00:00Z",
"series": [
{"entity": "plant:18W000000000AI3J", "name": P48, "provider": "esios"},
{"entity": "plant:18W000000000F3DO", "name": P48, "provider": "esios"},
{"entity": "unit:18W000000000AI2L",
"name": "production.per_unit.actual_generation_per_unit_a73.18w000000000ai2l", "provider": "entsoe"},
],
}
blocks = []
while True:
page = requests.post(f"{API}/timeseries/values", headers=HEADERS, json=body).json()
blocks += page["series"]
if not page["next"]:
break
body["cursor"] = page["next"]
for s in blocks:
print(s["entity"], [p["value"] for p in s.get("points", [])])
```
The Python version prints:
```text
plant:18W000000000AI3J [7.25, 7.25, 7.25, 7.0, 7.0]
plant:18W000000000F3DO [58.675, 56.7, 54.15, 51.375, 48.625]
unit:18W000000000AI2L []
```
## Response [#response]
One block per series, in the order listed. A block is what the one-series values call returns
for it (without `as_of`, which is on the page), so code that reads one reads the other.
```json
{
"start": "2026-11-03T12:00:00Z",
"end": "2026-11-03T13:00:00Z",
"as_of": "latest",
"series": [
{
"entity": "plant:18W000000000AI3J",
"name": "production.per_unit.esios_p48_final_programme_injection",
"provider": "esios",
"unit": "MWh",
"resolution": null,
"publication_time": "declared",
"columns": ["value"],
"points": [
{"valid_time": "2026-11-03T12:00:00Z", "value": 7.25, "knowledge_time": "2026-11-03T13:55:20Z", "annotation": null},
{"valid_time": "2026-11-03T12:15:00Z", "value": 7.25, "knowledge_time": "2026-11-03T13:55:20Z", "annotation": null},
{"valid_time": "2026-11-03T12:30:00Z", "value": 7.25, "knowledge_time": "2026-11-03T13:55:20Z", "annotation": null},
{"valid_time": "2026-11-03T12:45:00Z", "value": 7.0, "knowledge_time": "2026-11-03T13:55:20Z", "annotation": null},
{"valid_time": "2026-11-03T13:00:00Z", "value": 7.0, "knowledge_time": "2026-11-03T13:55:20Z", "annotation": null}
]
},
{
"entity": "plant:18W000000000F3DO",
…
},
{
"entity": "unit:18W000000000AI2L",
"name": "production.per_unit.actual_generation_per_unit_a73.18w000000000ai2l",
"provider": "entsoe",
"unit": "MW",
"resolution": "PT15M",
…
"points": []
}
],
"next": null
}
```
The A73 unit published nothing in that hour, so its `points` is empty; that is not an error. A
series with several [columns](https://grid.rebase.energy/docs/v1/guides/values/#columns) returns all of them, as `values` per point.
## Errors per series [#errors-per-series]
A series that cannot be read does not fail the call. Its block carries `error` instead of
`points`, with the `code` and `message` the one-series call would have returned, and the rest of
the list is still read:
```json
{
"entity": "plant:18W000000000AI3J",
"name": "production.per_unit.esios_p48_programme",
"provider": "esios",
"error": {
"code": "not_found",
"message": "no timeseries 'production.per_unit.esios_p48_programme' on plant:18W000000000AI3J",
"closest": ["production.per_unit.esios_p48_final_programme_injection"]
}
}
```
| `code` | When |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `not_found` | the entity, or the name on it, does not exist |
| `bad_request` | the provider does not publish this timeseries (the error lists the ones that do), or the window holds more than 100,000 points at this series' resolution |
| `platform_unavailable` | the data platform did not answer for this series; ask for it again |
The whole call is `400` only when the body itself is malformed: no `series`, more than 2,000, an
item missing `entity`, `name` or `provider`, `end` before `start`, or a `cursor` this API did not
issue for this list. It is `503` with `Retry-After` when the API is still loading its list of
plants, units and portfolios (for a minute or two after it starts); send the same body again.
## Paging [#paging]
A page holds whole series, in the order listed, up to **200,000 points** in total. When the next
series would go over, the page stops and `next` is set: send the same body again with `cursor`
set to it. A single series is still capped at 100,000 points, as in the one-series call, so a page
always holds at least one series.
For example, 1,500 plant schedules over 120 days at quarter hours (about 11,500 points each) come
back 17 series per page, in 89 calls instead of 1,500.
## Limits [#limits]
One call counts as one request against the rate limit, whatever the number of series. Without a
key a call may list at most 5 series ([Use without a key](https://grid.rebase.energy/docs/v1/guides/open-access/)). Only
the latest version is returned; for values as known at an earlier time (`as_of`), use the
one-series [values call](https://grid.rebase.energy/docs/v1/guides/values/).
# Metadata (https://grid.rebase.energy/docs/v1/guides/metadata/)
[`GET /entities/{entity}/timeseries/{name}`](https://grid.rebase.energy/docs/v1/reference/describe/timeseries-metadata/) returns the
definition of a timeseries and one metadata block per provider.
## Providers [#providers]
A provider is the organisation that published the series: `entsoe`, `svk`, `fingrid`, `elia`,
and so on; [Sources](https://grid.rebase.energy/docs/v1/guides/sources/) lists them all. When two providers publish the same quantity
for an entity, both are available side by side under one name, each with its own metadata. Clean
series built by Rebase use the provider `rebase` and state their inputs and method.
## Fields [#fields]
| Field | Meaning |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `definition.measures` | what the quantity is, in words; `definition.document` is the source document it comes from (an ENTSO-E article, a TSO page) |
| `component` | the member of the breakdown this series is (`wind_onshore`), with its siblings |
| `unit` | `MW`, `MWh`, `EUR/MWh`, … |
| `data_type` | `actual`, `forecast`, `price`, `capacity`, `schedule` or `other` |
| `columns` | per provider, the columns a point holds: `["value"]` for a plain series, or the members of a family published together (`["p10", "p50", "p90"]`); see [Reading values](https://grid.rebase.energy/docs/v1/guides/values/#columns) |
| `providers[].resolution` | the step between values, ISO 8601 (`PT15M`, `PT1H`, `P1D`); `resolution_history` lists past changes |
| `providers[].extent` | first and last `valid_time` with data |
| `providers[].latency_minutes` | p05 / p50 / p95 of the delay between the end of an interval and the first value for it, over the last seven days (for a series finer than one minute, its last 20,000 intervals) |
| `providers[].coverage` | share of the expected intervals with a value, over the same window |
| `providers[].publication_time` | `declared` when the provider states a publication time, `measured` when `knowledge_time` is the time the value was observed |
| `providers[].annotations_seen` | the annotation codes that occurred in the series, with counts |
| `providers[].values` | the path of the values call for this provider |
Values are served at the provider's native resolution and are not aggregated.
## Example [#example]
SE3 onshore wind, published by ENTSO-E:
```json
{
"entity": {
"id": "SE-SE3",
"kind": "price_zone",
"parent": "Sweden",
"country": "Sweden",
"sync_area": "sync:NSA"
},
"name": "production.realised_output.actual_generation_per_type.wind_onshore",
"definition": {
"path": "production.realised_output.actual_generation_per_type",
"measures": "actual net generation per production type (psrType), per area — from any publisher carrying the same numbers (ruling 2026-08-31, same-number-merge: absorbed litgrid_gamyba_101..106, eex_renewables_actual_generation_tso, tsoc_distributed_generation_estimate)",
"document": "A75",
"baseline": true,
"ref": "https://eepublicdownloads.entsoe.eu/clean-documents/Transparency/MoP_Ref2_DDD_v3r4.pdf"
},
"component": {
"key": "wind_onshore",
"description": "Actual generation (inBiddingZone side of A75) for ENTSO-E psrType B19 Wind Onshore.",
"siblings": [
"fossil_gas",
"gas",
"hydro",
"hydro_water_reservoir",
"marine",
"nuclear",
"other",
"solar",
"unknown",
"wind"
]
},
"unit": "MW",
"data_type": "actual",
"providers": [
{
"provider": "entsoe",
"resolution": "PT15M",
"resolution_history": [
{
"valid_from": "2015-01-04T23:00:00Z",
"resolution": "PT1H"
},
{
"valid_from": "2026-01-01T00:00:00Z",
"resolution": "PT15M"
}
],
"resolution_history_truncated": false,
"extent": {
"first": "2015-01-04T23:00:00Z",
"last": "2026-10-22T10:30:00Z"
},
"latency_minutes": {
"p05": 43,
"p50": 88,
"p95": 269
},
"coverage": 1.0,
"annotations_seen": {},
"publication_time": "measured",
"values": "/entities/SE-SE3/timeseries/production.realised_output.actual_generation_per_type.wind_onshore/values?provider=entsoe"
}
]
}
```
# Use without a key (https://grid.rebase.energy/docs/v1/guides/open-access/)
The Grid API is open: a request with no API key is answered. No sign-up, no token and no header are
needed to read European power system data (day-ahead prices, load, generation by type, forecasts,
cross-border flows, balancing, grid frequency).
This call works as it is, from any terminal or agent:
```bash
curl "https://grid.rebase.energy/api/v1/entities/SE-SE3/timeseries/price.day_ahead.day_ahead_auction_price/values?provider=entsoe&start=2026-11-09T00:00:00Z&end=2026-11-10T00:00:00Z"
```
```python
import requests
API = "https://grid.rebase.energy/api/v1"
name = "price.day_ahead.day_ahead_auction_price"
r = requests.get(
f"{API}/entities/SE-SE3/timeseries/{name}/values",
params={"provider": "entsoe", "start": "2026-11-09T00:00:00Z", "end": "2026-11-10T00:00:00Z"},
)
points = r.json()["points"] # [{"valid_time": ..., "value": ..., "knowledge_time": ...}, ...]
```
Replace `SE-SE3` with another price zone (`DE-LU`, `FR`, `NO-NO1`, `DK-DK1`, …) and the name with
another timeseries. [Search](https://grid.rebase.energy/docs/v1/guides/search/) finds the names on an entity, and the
[quickstart](https://grid.rebase.energy/docs/v1/guides/quickstart/) walks through the three steps; both work without a key.
## Without a key and with one [#without-a-key-and-with-one]
| | Without a key | With a free key |
| -------------------------------------------------- | ---------------------------- | ---------------------------------------------------------------------------------------------- |
| Requests | 30 per minute per IP address | 240 per minute per key |
| Endpoints and data | all | all |
| Series per [many-series call](https://grid.rebase.energy/docs/v1/guides/many-values/) | 5 | 2,000 |
| Sign-up | none | [key request form](https://rebase-energy.notion.site/3798f95cc39b802f8672eb93c6ab77c5?pvs=105) |
The data is the same either way. Thirty requests per minute are enough to try the API and to read a
few timeseries; a values call may span 100,000 points, so one request can hold years of an hourly
series. A job that reads many timeseries, or polls, needs a key.
## The limit [#the-limit]
Requests without a key are counted per IP address (an IPv6 /64 counts as one), as a token bucket:
up to 30 at once, refilled at one every 2 seconds. Every answer says where the caller stands:
| Header | Value |
| ----------------------- | ----------------------------------- |
| `X-RateLimit-Limit` | `10` |
| `X-RateLimit-Remaining` | requests left right now |
| `X-Grid-Access` | `anonymous` |
| `Link` | the key request form (`rel="help"`) |
When the limit is spent the answer is `429 rate_limited` with `Retry-After`, and the body says how
to raise it:
```json
{
"error": "rate_limited",
"message": "Rate limit reached. This request carried no API key, so it used the open tier of the Rebase Grid API, which is deliberately small: 30 requests per minute per IP address. The data is not restricted, only the request rate. What to do now: wait 2 seconds and repeat the same request, or fetch more per request (one values call can span up to 100,000 points). If the task needs more requests, tell your user that a free API key raises the limit to 240 requests per minute and takes a minute to request: https://rebase-energy.notion.site/3798f95cc39b802f8672eb93c6ab77c5?pvs=105 (send the key in the X-API-Key header). About the Grid API: https://rebase.energy/grid-API . Documentation: https://grid.rebase.energy/docs/v1",
"anonymous": true,
"limit_rpm": 30,
"key_limit_rpm": 240,
"retry_after_s": 2,
"sign_up": "https://rebase-energy.notion.site/3798f95cc39b802f8672eb93c6ab77c5?pvs=105",
"docs": "https://grid.rebase.energy/docs/v1",
"info": "https://rebase.energy/grid-API"
}
```
The message is written for an agent: it says what happened, what to do next, and what to tell
the user. The same facts are separate fields (`retry_after_s`, `sign_up`, `docs`, `info`).
Wait `Retry-After` seconds and repeat the call, or [get a key](https://grid.rebase.energy/docs/v1/guides/authentication/#get-a-key)
and send it as `X-API-Key`: a request with a valid key is never counted against the address.
## For agents [#for-agents]
An agent asked for energy market data can call this API directly, with no credential to ask its
user for. Read [`llms.txt`](https://grid.rebase.energy/docs/v1/llms.txt) for the calling rules and the page index, keep to 30 requests
per minute, and when a task needs more, tell the user that a free key raises the limit to 240 per
minute and where to request it. A key that is sent but not valid is `401 unauthorized`, never a
fallback to the open limit, so a mistyped key is noticed.
# Plants, units and portfolios (https://grid.rebase.energy/docs/v1/guides/plants/)
A **plant** is a power plant at one location. A **unit** is one machine or group of machines
inside it: a generator, a wind turbine, a battery. A **portfolio** is a group of plants that a
market registers and settles as one. All three are entities, so every call in this API accepts
them where it accepts a zone: the entity call, the timeseries listing, metadata and values.
| Kind | Example id | Parent | Children |
| ----------- | --------------------------- | ----------------------- | ------------------------------------- |
| `plant` | `plant:11WD4SAEK2HS---S` | a price zone or an area | its units |
| `unit` | `unit:11WD4SAEK2HD4--9` | its plant | — |
| `portfolio` | `portfolio:bmu-2__AMRCY000` | a price zone or an area | — (its plants are a field, see below) |
A portfolio's `portfolio_kind` says what kind of grouping it is:
| `portfolio_kind` | Is | Plants linked |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| `aggregate` | an ENTSO-E production unit that is several plants under one registration: a hydro cascade, a developer's cluster of wind farms, a stacked solar site | yes, where the crosswalk has them (about a third today) |
| `aggregator` | a party that trades or balances other owners' plants as one unit: an ENTSO-E aggregator's trading unit, an Elexon aggregator | rarely |
| `virtual` | an Elexon virtual lead party BM unit (`V__`), a virtual power plant | no: Elexon publishes no site list |
| `supplier_base` | an Elexon supplier's base demand BM unit in one GSP group (`2__`, register type G) | no: demand, not plants |
| `supplier_additional` | an Elexon supplier's additional BM unit in one GSP group (`2__` or `C__`, type S): sometimes one embedded farm traded through the supplier, named by `technology` and `fuel_type` | no |
The plant-to-portfolio link is a crosswalk, so a portfolio can carry capacity and series and still
have `plants: []`. The card's `plants` count is the cheap way to tell before calling the entity.
The register a record comes from is its `provider`: `entsoe` (production and generation units),
`bmrs` (Elexon BM units), `mastr` (the German Marktstammdatenregister), `gem` (Global Energy
Monitor), `epias` (Turkey), `vbk` (Sweden), `energistyrelsen` (Denmark) and `georisques` (France). The register today holds about 57,000 plants, 98,000 units and
1,100 portfolios.
## Ids and names [#ids-and-names]
The id is the kind prefix and the register's key: `plant:` followed by an ENTSO-E EIC, a MaStR
number (`plant:mastr-SEL926745834017`), a GEM location (`plant:gem-L100000601739`). A **name**
is accepted after the same prefix: `plant:Säckingen hydroelectric plant` resolves to
`plant:11WD4SAEK2HS---S`. Plant names match both the register name and the GEM common name.
Names are not unique: `plant:Schluchseewerk AG` is 404 and lists the three candidate ids in
`closest`. Responses always return the key in `id`, so use that for anything stored.
## Cards [#cards]
Wherever a plant, unit or portfolio appears, it appears as a card: a fixed set of fields per kind,
the same in a `parent`, a child line and a list item, so listing a plant's units or a portfolio's
plants does not cost one call per line.
| Kind | Card fields |
| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| plant | `name`, `common_name`, `parent`, `technology`, `sub_technology`, `psr_type`, `capacity_mw`, `location` (`latitude`, `longitude`, `accuracy`), `portfolio`, `provider` |
| unit | `name`, `parent`, `type`, `production_type`, `psr_type`, `capacity_kw`, `energy_mwh`, `fuel`, `provider` — no `location`: a unit sits at its plant's point |
| portfolio | `name`, `parent`, `portfolio_kind` (`aggregate`, `aggregator`, `supplier_base`, `supplier_additional`, `virtual`), `technology`, `capacity_mw`, `demand_capacity_mw`, `lead_party`, `fuel_type`, `transmission_loss_factor` and `gsp_group` (GB BM units), `provider` |
A unit has no location of its own: it sits at its plant's `location`, and the plant's `accuracy`
applies to it. `accuracy` is `exact` (the plant's own point), `approximate` (municipality
precision, or a matched point rated so by its source) or `placeholder` (a stand-in the source
uses when it has no position, a country or municipality centroid shared by many plants; skip
these when mapping). A portfolio has no location at all.
Fields the register did not fill are omitted. The entity call adds the rest: external ids
(`eic`, `gem_location_id`, `mastr_unit_id`, `bmu_id`, …), the series the plant publishes, commissioning, operator,
voltage and, for GEM-merged plants, the `provenance` of the merge.
## The entity call [#the-entity-call]
[`GET /entities/{entity}`](https://grid.rebase.energy/docs/v1/reference/discover/entity/) on a plant returns its card, one hop up in
`parent` (its zone, with that zone's timeseries count), its `portfolio` inline, and its units as
cards under `children`. A unit returns its plant's card as `parent` and no children. A portfolio
has no children either: a plant names its portfolio in its `portfolio` field, the way a site
does on the platform, so the portfolio call returns the plants that name it under `plants`, as
plant cards, with their summed capacity in `plants_capacity_mw` beside the register's own
`capacity_mw`. The same plants are also the list `GET /entities/{portfolio}/plants`, and their
units `GET /entities/{portfolio}/units`.
A zone's entity call does not list its plants. Its `children` carry one summary line per kind,
with the count, the capacity and how many hold timeseries, and the path of the list:
```json
{"kind": "plant", "count": 21107, "capacity_mw": 212583, "with_timeseries": 119, "list": "/entities/DE-LU/plants"}
```
```bash
curl "$API/entities/plant:11WD4SAEK2HS---S" -H "X-API-Key: $KEY"
```
```python
r = requests.get(f"{API}/entities/plant:11WD4SAEK2HS---S", headers=HEADERS)
plant = r.json()
units = plant["children"]
```
## Lists [#lists]
Three paged lists return the cards under an entity, that entity and everything below it: a
country, a zone, an area. On a plant, `units` lists its units; on a portfolio, `plants` lists the
plants that name it and `units` the units of those plants. There is no Europe-wide list and a
synchronous area holds nothing: to sweep everything, call once per country plus the zones with no
country (`GB`, `SEM`), which are the top level of `GET /entities`. Results page with `next`:
here it is the path and query of the next page (the same filters, with `cursor` set), to request
as it is, not a value to pass as `cursor`. `limit` is 100 by default and at most 1000.
| List | Filters |
| --------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| [`GET /entities/{entity}/plants`](https://grid.rebase.energy/docs/v1/reference/discover/plants/) | `technology`, `min_mw`, `has_timeseries`, `bbox`, `provider`, `portfolio` |
| [`GET /entities/{entity}/units`](https://grid.rebase.energy/docs/v1/reference/discover/units/) | `type`, `production_type`, `fuel`, `min_kw`, `has_timeseries`, `bbox`, `provider` |
| [`GET /entities/{entity}/portfolios`](https://grid.rebase.energy/docs/v1/reference/discover/portfolios/) | `portfolio_kind`, `min_mw`, `has_timeseries`, `provider` |
`bbox` is `minLon,minLat,maxLon,maxLat`. `has_timeseries=true` keeps the records that hold at
least one timeseries, which is the usual first filter: most plants in a register publish nothing
of their own.
```bash
# hydro plants of 100 MW or more in DE-LU
curl "$API/entities/DE-LU/plants?technology=hydro&min_mw=100" -H "X-API-Key: $KEY"
# batteries of 10 MW or more
curl "$API/entities/DE-LU/units?type=storage&min_kw=10000" -H "X-API-Key: $KEY"
# the GB suppliers' base demand portfolios
curl "$API/entities/GB/portfolios?portfolio_kind=supplier_base" -H "X-API-Key: $KEY"
```
```python
# every plant in DE-LU that holds a timeseries
items, cursor = [], None
while True:
r = requests.get(
f"{API}/entities/DE-LU/plants",
headers=HEADERS,
params={"has_timeseries": "true", "limit": 1000, "cursor": cursor},
)
page = r.json()
items += page["items"]
if not page["next"]:
break
cursor = page["next"].split("cursor=")[1]
```
## Timeseries on a plant [#timeseries-on-a-plant]
Series are held by the record that publishes them: installed capacity per production unit on the
plant, actual generation per generation unit on the unit, a BM unit's metered output on the
portfolio. A plant's `timeseries.total` counts its own series, not its units'.
[`GET /entities/{entity}/timeseries`](https://grid.rebase.energy/docs/v1/reference/discover/timeseries-names/) on a plant lists its
own series and, under `children`, those of its units; on a portfolio, its own series only. Search
scoped to a zone (`GET /timeseries?entity=DE-LU`) covers the plants, units and portfolios under
it as well.
Metadata and values are read per owner, with the same routes and the same `as_of` forms as a
zone:
```bash
curl "$API/entities/plant:11WD4SAEK2HS---S/timeseries" -H "X-API-Key: $KEY"
curl "$API/entities/plant:11WD4SAEK2HS---S/timeseries/capacity.installed.installed_capacity_per_unit_a71.11wd4saek2hs___s/values?provider=entsoe&start=2026-01-01T00:00:00Z&end=2026-12-31T23:00:00Z" \
-H "X-API-Key: $KEY"
```
```python
plant = "plant:11WD4SAEK2HS---S"
names = requests.get(f"{API}/entities/{plant}/timeseries", headers=HEADERS).json()
name = names["timeseries"][0]["name"]
r = requests.get(
f"{API}/entities/{plant}/timeseries/{name}/values",
headers=HEADERS,
params={"provider": "entsoe", "start": "2026-01-01T00:00:00Z", "end": "2026-12-31T23:00:00Z"},
)
points = r.json()["points"]
```
# Production by type as a stacked bar chart (https://grid.rebase.energy/docs/v1/guides/production-by-type/)
Production by type is one timeseries per type, all sharing the definition
`production.realised_output.actual_generation_per_type`; the type is the last part of the name
(`nuclear`, `wind_onshore`, `solar`, …).
This example plots France for the last seven days, as the daily average of each type:
**Find the types.** One search for the definition on the price zone lists every type the
provider publishes there.
**Read each type.** One values call per type, over the same window. A type with no value in the
window is left out.
**Stack them**, one bar per day, the largest type at the bottom.
```python
import os
from datetime import datetime, timedelta, timezone
import matplotlib.pyplot as plt
import pandas as pd
import requests
API = "https://grid.rebase.energy/api/v1"
HEADERS = {"X-API-Key": os.environ["GRID_API_KEY"]}
ENTITY = "FR" # France has one price zone; for a country with several, repeat per zone and add up
DEFINITION = "production.realised_output.actual_generation_per_type"
today = datetime.now(timezone.utc).replace(hour=0, minute=0, second=0, microsecond=0)
start, end = today - timedelta(days=7), today - timedelta(minutes=15)
# 1. Discover: every production type ENTSO-E publishes for the zone.
r = requests.get(
f"{API}/timeseries",
headers=HEADERS,
params={"entity": ENTITY, "q": DEFINITION, "provider": "entsoe", "limit": 1000},
)
r.raise_for_status()
names = [item["name"] for item in r.json()["items"] if item["name"].startswith(DEFINITION + ".")]
# 2. Read: one call per production type. A type with no value in the window is left out.
daily = {}
for name in names:
r = requests.get(
f"{API}/entities/{ENTITY}/timeseries/{name}/values",
headers=HEADERS,
params={"provider": "entsoe", "start": start.isoformat(), "end": end.isoformat()},
)
r.raise_for_status()
points = pd.DataFrame(r.json()["points"])
if points.empty:
continue
values = points.set_index(pd.to_datetime(points["valid_time"]))["value"]
daily[name.rsplit(".", 1)[1]] = values.resample("1D").mean()
# 3. Plot: one bar per day, one segment per type, largest at the bottom.
table = pd.DataFrame(daily).fillna(0)
table = table[table.mean().sort_values(ascending=False).index]
ax = table.plot.bar(stacked=True, figsize=(10, 5), width=0.8, colormap="tab20")
ax.set_xticklabels([d.strftime("%d %b") for d in table.index], rotation=0)
ax.set_xlabel("")
ax.set_title(f"{ENTITY} production by type, daily average")
ax.set_ylabel("MW")
ax.legend(fontsize=7, ncol=2, loc="upper left", bbox_to_anchor=(1, 1))
plt.tight_layout()
plt.show()
```
Production by type is published per price zone. France is one price zone; for a country with
several (Sweden, Norway, Italy), read each of its price zones, listed as its children in the
[entity tree](https://grid.rebase.energy/docs/v1/guides/entities/), and add them up.
The script is [`docs-site/examples/production_by_type.py`](https://github.com/rebase-energy/rebase-grid/blob/main/docs-site/examples/production_by_type.py);
it needs `requests`, `pandas` and `matplotlib`, and the key in `GRID_API_KEY`.
# Quickstart (https://grid.rebase.energy/docs/v1/guides/quickstart/)
This walkthrough reads the day-ahead auction price in Sweden's `SE-SE3` (Stockholm), Denmark's
`DK-DK1` (Jutland and Funen) and Norway's `NO-NO1` (Oslo). It assumes the `API` and `KEY` (or
`HEADERS`) setup from [Authentication](https://grid.rebase.energy/docs/v1/guides/authentication/). Where a response below is shortened,
`…` marks what was left out.
## 1. Find the timeseries [#1-find-the-timeseries]
Search for "day-ahead" among the ENTSO-E price timeseries of a zone:
```bash
curl "$API/timeseries?entity=SE-SE3&category=price&q=day-ahead&provider=entsoe" -H "X-API-Key: $KEY"
```
```python
r = requests.get(
f"{API}/timeseries",
headers=HEADERS,
params={"entity": "SE-SE3", "category": "price", "q": "day-ahead", "provider": "entsoe"},
)
items = r.json()["items"]
```
```json
{
"total": 1,
"items": [
{
"entity": "SE-SE3",
"name": "price.day_ahead.day_ahead_auction_price",
"provider": "entsoe",
"data_type": "price",
"metadata": "/entities/SE-SE3/timeseries/price.day_ahead.day_ahead_auction_price"
}
],
"next": null
}
```
The day-ahead price is named `price.day_ahead.day_ahead_auction_price`, and the name is the same in
every zone. Drop `provider` to see every organisation that publishes it.
## 2. Describe it [#2-describe-it]
The `metadata` link from the search says where the zone sits, what the timeseries measures and in
which unit, and for each provider how often it has a value, how far back it goes and how early it is
published (shown here for ENTSO-E only):
```bash
curl "$API/entities/SE-SE3/timeseries/price.day_ahead.day_ahead_auction_price" -H "X-API-Key: $KEY"
```
```python
name = "price.day_ahead.day_ahead_auction_price"
meta = requests.get(f"{API}/entities/SE-SE3/timeseries/{name}", headers=HEADERS).json()
```
```json
{
"entity": {
"id": "SE-SE3",
"kind": "price_zone",
"parent": "Sweden",
"country": "Sweden",
"sync_area": "sync:NSA"
},
"name": "price.day_ahead.day_ahead_auction_price",
"definition": {
"path": "price.day_ahead.day_ahead_auction_price",
"measures": "day-ahead auction clearing price per bidding zone",
"document": "A44",
"baseline": true,
"ref": "https://eepublicdownloads.entsoe.eu/clean-documents/Transparency/MoP_Ref2_DDD_v3r4.pdf"
},
"unit": "EUR/MWh",
"data_type": "price",
"providers": [
{
"provider": "entsoe",
"resolution": "PT15M",
"resolution_history": [
{"valid_from": "2014-12-31T23:00:00Z", "resolution": "PT1H"},
{"valid_from": "2026-09-09T22:00:00Z", "resolution": "PT15M"}
],
"extent": {
"first": "2014-12-31T23:00:00Z",
"last": "2026-11-05T22:45:00Z"
},
"latency_minutes": {"p05": -1985, "p50": -1325, "p95": -680},
"coverage": 1.0,
"annotations_seen": {"a03_forward_fill": 3},
"publication_time": "measured",
"values": "/entities/SE-SE3/timeseries/price.day_ahead.day_ahead_auction_price/values?provider=entsoe",
…
},
…
],
…
}
```
ENTSO-E's prices go back to 2015: hourly at first, quarter-hourly since September 2026
(`resolution_history`). Over the last seven days no quarter hour was missing (`coverage` 1.0).
`latency_minutes` is negative because a day-ahead price is published before the quarter hour it is
for, typically about 22 hours ahead; so `extent.last` is already tomorrow evening. See [Metadata](https://grid.rebase.energy/docs/v1/guides/metadata/) for every field.
## 3. Read the values [#3-read-the-values]
Read one hour of ENTSO-E prices for each of the three zones. A values call reads one timeseries in
one zone, so three zones take three calls:
```bash
for zone in SE-SE3 DK-DK1 NO-NO1; do
curl "$API/entities/$zone/timeseries/price.day_ahead.day_ahead_auction_price/values?provider=entsoe&start=2026-11-03T12:00:00Z&end=2026-11-03T13:00:00Z" \
-H "X-API-Key: $KEY"
done
```
```python
for zone in ["SE-SE3", "DK-DK1", "NO-NO1"]:
r = requests.get(
f"{API}/entities/{zone}/timeseries/{name}/values",
headers=HEADERS,
params={
"provider": "entsoe",
"start": "2026-11-03T12:00:00Z",
"end": "2026-11-03T13:00:00Z",
},
)
for p in r.json()["points"]:
print(zone, p["valid_time"], p["value"])
```
The full response for `SE-SE3`, one point per quarter hour (`end` is inclusive, so 12:00 to 13:00 is
five points):
```json
{
"entity": "SE-SE3",
"name": "price.day_ahead.day_ahead_auction_price",
"provider": "entsoe",
"unit": "EUR/MWh",
"resolution": "PT15M",
"publication_time": "measured",
"columns": ["value"],
"as_of": "latest",
"points": [
{"valid_time": "2026-11-03T12:00:00Z", "value": 144.57, "knowledge_time": "2026-11-02T12:36:27.898646Z", "annotation": null},
{"valid_time": "2026-11-03T12:15:00Z", "value": 143.3, "knowledge_time": "2026-11-02T12:36:27.898646Z", "annotation": null},
{"valid_time": "2026-11-03T12:30:00Z", "value": 155.45, "knowledge_time": "2026-11-02T12:36:27.898646Z", "annotation": null},
{"valid_time": "2026-11-03T12:45:00Z", "value": 182.57, "knowledge_time": "2026-11-02T12:36:27.898646Z", "annotation": null},
{"valid_time": "2026-11-03T13:00:00Z", "value": 125.6, "knowledge_time": "2026-11-02T12:36:27.898646Z", "annotation": null}
]
}
```
And what the Python version prints:
```text
SE-SE3 2026-11-03T12:00:00Z 144.57
SE-SE3 2026-11-03T12:15:00Z 143.3
SE-SE3 2026-11-03T12:30:00Z 155.45
SE-SE3 2026-11-03T12:45:00Z 182.57
SE-SE3 2026-11-03T13:00:00Z 125.6
DK-DK1 2026-11-03T12:00:00Z 228.53
DK-DK1 2026-11-03T12:15:00Z 236.74
DK-DK1 2026-11-03T12:30:00Z 233.37
DK-DK1 2026-11-03T12:45:00Z 231.08
DK-DK1 2026-11-03T13:00:00Z 224.57
NO-NO1 2026-11-03T12:00:00Z 174.6
NO-NO1 2026-11-03T12:15:00Z 174.82
NO-NO1 2026-11-03T12:30:00Z 174.79
NO-NO1 2026-11-03T12:45:00Z 175.53
NO-NO1 2026-11-03T13:00:00Z 174.44
```
`valid_time` is the quarter hour the price is for; `knowledge_time` is when it became known, here
just after the auction cleared at midday the day before. `annotation` is `null` for a value as
published, otherwise a code such as `a03_forward_fill` (the provider carried the previous value
forward). [Reading values](https://grid.rebase.energy/docs/v1/guides/values/) covers the time range, earlier versions (`as_of`) and
paging.
# Search (https://grid.rebase.energy/docs/v1/guides/search/)
[`GET /timeseries`](https://grid.rebase.energy/docs/v1/reference/discover/search/) finds timeseries across all entities. Every
parameter is optional and they combine:
| Parameter | Matches |
| ------------------------- | -------------------------------------------------------------------------- |
| `entity` | the entity and its descendants |
| `q` | free text over the name, the definition text and the component description |
| `category`, `subcategory` | the first two parts of the name |
| `provider` | the provider id |
| `data_type` | `actual`, `forecast`, `price`, `capacity`, `schedule` or `other` |
Each item carries the path of its metadata call. Results page with `next`, passed back as
`cursor`.
To list the timeseries of one entity instead, including those on its relations (the borders it
touches), use [`GET /entities/{entity}/timeseries`](https://grid.rebase.energy/docs/v1/reference/discover/timeseries-names/).
```bash
# every forecast in SE3
curl "$API/timeseries?entity=SE-SE3&data_type=forecast" -H "X-API-Key: $KEY"
```
```python
# every forecast in SE3
r = requests.get(
f"{API}/timeseries",
headers=HEADERS,
params={"entity": "SE-SE3", "data_type": "forecast"},
)
```
# Sources (https://grid.rebase.energy/docs/v1/guides/sources/)
{/* Generated by docs-site/scripts/generate.ts from docs/grid-api/providers.yaml and src/gridapi/licences.yaml. */}
The API serves data from 36 providers. The provider id is the value of the `provider` field and parameter.
The data stays under its publisher's terms: when you republish it, follow the licence and show the credit line listed here.
Every metadata and values response carries the same licence in its `licence` field.
| Provider | Organisation | Country | Licence | Credit line |
| -------------------- | --------------------------------------------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `admie` | [IPTO (ADMIE)](https://www.admie.gr) | Greece | [no published terms](https://www.admie.gr/en/market/market-statistics/file-download-api) | |
| `amprion` | [Amprion](https://www.amprion.net) | Germany | [no published terms](https://www.amprion.net) | |
| `apg` | [Austrian Power Grid](https://www.apg.at) | Austria | [no published terms](https://transparency.apg.at) | |
| `bmrs` | [Elexon (BMRS)](https://bmrs.elexon.co.uk) | Great Britain | [BMRS Data Licence](https://www.elexon.co.uk/data/balancing-mechanism-reporting-agent/copyright-licence-bmrs-data/) | Contains BMRS data © Elexon Limited copyright and database right \[year]. |
| `ceps` | [ČEPS](https://www.ceps.cz) | Czech Republic | [no published terms](https://www.ceps.cz/en/all-data) | |
| `elering` | [Elering](https://elering.ee) | Estonia | [no published terms](https://dashboard.elering.ee/assets/api-doc.html) | |
| `elia` | [Elia](https://www.elia.be) | Belgium | [Elia Open Data Licence](https://www.elia.be/en/grid-data/elia-open-data-license) | Elia Transmission Belgium SA (dataset pages list this as attribution) |
| `ember` | [Ember](https://ember-energy.org) | Global | [CC BY 4.0](https://ember-energy.org/about/licence/) | Ember (credit Ember as source; exact text not specified) |
| `ems` | [Elektromreža Srbije (EMS)](https://www.ems.rs) | Serbia | [no published terms](https://transparency.ems.rs) | |
| `energinet` | [Energinet](https://www.energidataservice.dk) | Denmark | [Conditions for use of Danish public-sector data](https://www.energidataservice.dk/Conditions_for_use_of_Danish_public_sector_data-License_for_use_of_data_in_ED.pdf) | Contains data used pursuant to 'Conditions for use of Danish public-sector data' from the Energi Data Service portal ([www.energidataservice.dk](http://www.energidataservice.dk)). |
| `entsoe` | [ENTSO-E Transparency Platform](https://transparency.entsoe.eu) | Europe | [ENTSO-E Transparency Platform Terms of Use](https://eepublicdownloads.entsoe.eu/clean-documents/mc-documents/transparency-platform/ENTSOE_Transparency_Terms_Conditions.pdf) | Mention the ENTSO-E Transparency Platform as the source of publication (no exact wording prescribed) |
| `epias` | [EPİAŞ (EXIST Transparency Platform)](https://seffaflik.epias.com.tr) | Türkiye | [no published terms](https://seffaflik.epias.com.tr) | |
| `esett` | [eSett](https://www.esett.com) | Nordics | [CC0 1.0](https://opendata.esett.com) | |
| `esios` | [Red Eléctrica (ESIOS)](https://www.esios.ree.es) | Spain | [no published terms](https://www.esios.ree.es) | |
| `eso_bg` | [Electricity System Operator (ESO)](https://www.eso.bg) | Bulgaria | [no published terms](https://www.eso.bg) | |
| `fiftyhertz` | [50Hertz](https://www.50hertz.com) | Germany | [no published terms](https://www.50hertz.com/en/Grid-Data/Grid-load) | |
| `fingrid` | [Fingrid](https://www.fingrid.fi) | Finland | [CC BY 4.0](https://data.fingrid.fi/en/about) | Source Fingrid / data.fingrid.fi, license CC 4.0 BY |
| `kraftnat` | [Kraftnät Åland](https://kraftnat.ax) | Åland | [no published terms](https://kraftnat.ax) | |
| `lccc` | [Low Carbon Contracts Company](https://www.lowcarboncontracts.uk) | Great Britain | [UK Open Government Licence v3.0](https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/) | Contains public sector information licensed under the Open Government Licence v3.0 (OGL standard wording; LCCC specifies no other credit) |
| `litgrid` | [Litgrid](https://www.litgrid.eu) | Lithuania | [CC BY 4.0](https://www.litgrid.eu/atviri-duomenys) | Source: Litgrid |
| `mavir` | [MAVIR](https://www.mavir.hu) | Hungary | [no published terms](https://mavir.hu/web/mavir/jogi-nyilatkozat) | |
| `moldelectrica` | [Moldelectrica](https://moldelectrica.md) | Moldova | [no published terms](https://moldelectrica.md) | |
| `ned` | [Nationaal Energie Dashboard](https://ned.nl) | Netherlands | [NED general terms](https://ned.nl/nl/algemene-voorwaarden) | Bronvermelding required, including NED's logo and a link to its website (Art. 8.2) |
| `neso` | [National Energy System Operator (NESO)](https://www.neso.energy) | Great Britain | [NESO Open Data Licence](https://www.neso.energy/data-portal/NESO-open-licence) | Supported by National Energy SO Open Data |
| `netztransparenz` | [Netztransparenz (German TSOs)](https://www.netztransparenz.de) | Germany | [Impressum: reproduction needs written consent](https://www.netztransparenz.de/de-de/Impressum) | |
| `pse` | [PSE](https://www.pse.pl) | Poland | [no published terms](https://raporty.pse.pl/) | |
| `ree_apidatos` | [Red Eléctrica (REData API)](https://www.ree.es) | Spain | [REE legal notice (non-commercial reuse)](https://www.ree.es/es/aviso-legal) | Credit REE as source, do not alter the meaning, state date of last update |
| `ree_demanda` | [Red Eléctrica (demand tracking)](https://demanda.ree.es) | Spain | [REE legal notice (non-commercial reuse)](https://www.ree.es/es/aviso-legal) | Credit REE as source, do not alter the meaning, state date of last update |
| `rte` | [RTE](https://www.rte-france.com) | France | [Licence Ouverte v2.0 (Etalab)](https://odre.opendatasoft.com/explore/dataset/eco2mix-national-tr/information/) | Etalab 2.0: mention source and update date (RTE / ODRE); no specific credit string required |
| `semopx` | [SEMOpx](https://www.semopx.com) | Ireland | [no published terms](https://www.semopx.com/disclaimer) | |
| `smard` | [SMARD (Bundesnetzagentur)](https://www.smard.de) | Germany | [CC BY 4.0](https://www.smard.de/en/datennutzung) | Bundesnetzagentur \| SMARD.de |
| `smartgriddashboard` | [EirGrid Smart Grid Dashboard](https://www.smartgriddashboard.com) | Ireland | [EirGrid Group Open Data Licence](https://www.smartgriddashboard.com/all/open-data-license/) | Supported by EirGrid Group Data |
| `statnett` | [Statnett](https://www.statnett.no) | Norway | [no published terms](https://www.statnett.no/en/for-stakeholders-in-the-power-industry/data-from-the-power-system/) | |
| `svk` | [Svenska kraftnät](https://www.svk.se) | Sweden | [CC BY 4.0](https://data.svk.se/about) | Source: Svenska kraftnät (data.svk.se) |
| `terna` | [Terna (download centre)](https://www.terna.it) | Italy | [no published terms](https://www.terna.it/en/about-us/legal-notes) | |
| `terna_api` | [Terna (public API)](https://developer.terna.it) | Italy | [Terna API Terms of Use](https://developer.terna.it/API_Terms_of_Use) | |
# Timeseries names (https://grid.rebase.energy/docs/v1/guides/timeseries-names/)
A timeseries is identified by its entity, its name and its provider. Names have three or four
parts, `category.sub_category.definition[.component]`:
* `consumption.realised_load.total_load`
* `consumption.load_forecast.day_ahead_total_load_forecast`
* `production.realised_output.actual_generation_per_type.wind_onshore`
* `production.forecast.wind_generation_forecast.onshore_day_ahead`
* `price.day_ahead.day_ahead_auction_price`
* `exchange.physical_flow.physical_flow` (on a border)
* `exchange_capacity.ntc_atc.day_ahead_ntc` (on a border)
A name exists only on the entities whose provider publishes it. `day_ahead_ntc`, for one, is on
the borders where capacity is allocated border by border; the flow-based borders of central
western Europe (`border:AT~DE-LU`, `border:BE~FR`, `border:DE-LU~FR` and their neighbours) have
no such series, because their capacity is computed for the region as a whole. List an entity's
names with `GET /entities/{entity}/timeseries` before asking for values.
| Part | Says | Example |
| ------------ | ------------------------------------------------------------------------------ | ---------------------------- |
| category | the kind of quantity | `production` |
| sub-category | the kind of statement: a measured actual, a forecast, a plan, a market outcome | `realised_output` |
| definition | the precise quantity | `actual_generation_per_type` |
| component | one member of a breakdown: a production type, a direction, a reserve product | `wind_onshore` |
## Categories [#categories]
Every category, its sub-categories and the definitions with data today.
{/* Generated by docs-site/scripts/generate.ts from docs/grid-api/catalog_in_use.json. */}
| Definition | Measures |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `activated_balancing_energy_volumes` | the volume of balancing energy ACTIVATED, per reserve product and direction — the energy actually delivered, from any publisher (merged 2026-08-31 from \~54 per-source/product/channel publications:… |
| `afrr_activated_energy` | activated aFRR (automatic frequency restoration reserve) balancing energy — the energy actually delivered for this product, any publisher; direction, activation channel, place and resolution are ax… |
| `bid_offer_acceptance` | accepted balancing mechanism bid/offer instructions per BM unit (BOALF), with per-acceptance level profiles — the MW levels the SO instructs a BM unit to deliver, comprising acceptance number, time… |
| `bid_offer_acceptance_volume` | accepted balancing mechanism energy per BM unit and settlement period, in MWh, from settlement (BOAV) — the volume NESO's accepted bids (≤ 0, the unit delivers less) or offers (≥ 0, the unit delive… |
| `fcr_activated_energy` | activated FCR (frequency containment reserve) balancing energy — the energy actually delivered for this product, any publisher; direction, activation channel, place and resolution are axes. Product… |
| `hour_change_regulation_down_volume` | volume of DOWN-direction hour-change regulation, in MW per hour — the down-direction twin of hour\_change\_regulation\_up\_volume |
| `hour_change_regulation_up_volume` | volume of UP-direction hour-change regulation, in MW per hour — regulation that moves a planned production change to start 15 minutes earlier or later than planned, to damp the frequency disturbanc… |
| `mfrr_activated_energy` | activated mFRR (manual frequency restoration reserve) balancing energy — the energy actually delivered for this product, any publisher; direction, activation channel, place and resolution are axes.… |
| `mfrr_balancing_regulation_activation` | activated mFRR day-ahead balancing regulation volume (MW) — balancing power activated by Fingrid in the mFRR energy market through direct activation (DA); positive = upward, negative = downward |
| `mfrr_special_regulation_activation` | activated mFRR special regulation volume (MW) — balancing power activated by Fingrid for special regulation needs in the mFRR energy market through scheduled (SA) or direct (DA) activation |
| `other_power_transactions_down` | down-regulation from other power transactions deemed necessary for the power system, hourly volume in MWh/h |
| `other_power_transactions_up` | up-regulation from other power transactions deemed necessary for the power system, hourly volume in MWh/h |
| Definition | Measures |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `aggregated_balancing_energy_bids` | aggregated bids for balancing energy submitted to the TSO per reserve product, per area — the volume and price of bids received, before activation |
| `balancing_energy_bids_a37` | the individual balancing energy bids submitted to a TSO under GL EB — one entry per bid with its offered volume, price, direction and product, before any activation decision |
| Definition | Measures |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `area_control_error_open_loop` | the OPEN-LOOP Area Control Error of a control area — the area's net imbalance computed as if no balancing reserves had been activated, published as a single timeseries. Signed: positive is a surplu… |
| `current_balancing_state` | the current balancing state of an LFC area — the area control error and the balancing energy already activated to correct it, published at sub-MTU (typically per-minute) granularity while the marke… |
| `imbalance_power_per_border` | imbalance power (the difference between measured and commercial transmission) on a specific border, signed — positive when the TSO has sold imbalance power to the neighbouring area, negative when b… |
| `imbalance_volume` | the total imbalance volume of a control area or bidding zone in a settlement period — the net position the TSO had to balance, signed; any settlement system's publication of it (merged 2026-08-31:… |
| `imbalance_volume_negative` | the negative (downward) imbalance energy volume settled in a control area or bidding zone — the MWh of negative imbalance (system long), aggregated per settlement period |
| `imbalance_volume_positive` | positive imbalance energy volume (Ausgleichsvolumen (+)) of a control area or bidding zone in a settlement period — the volume of upward imbalance energy, in MWh |
| `mfrr_dominating_direction` | dominating direction in the mFRR energy market, per bidding zone and delivery period; -1 = down-regulation, 1 = up-regulation, 0 = no direction or equal activation in both directions. A market-stat… |
| `renewables_support_portfolio_imbalance_quantity` | the imbalance quantity of the renewables-support-mechanism portfolio in a settlement period — the deviation between what the scheme offered and what its plants injected |
| `system_imbalance_forecast` | forecast of the system imbalance (net imbalance position) of a control area, published as a regression forecast value plus categorical probability bins; distinct from the realised imbalance volume |
| Definition | Measures |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `indicated_margin` | indicated day-ahead margin per GB boundary (national or zonal), per settlement period — the indicative surplus of generation over demand and exports |
| `loss_of_load_probability_and_derated_margin` | Loss of Load Probability (LoLP, value 0-1) and De-rated Margin (MW) per settlement period, published for five forecast horizons (1h, 2h, 4h, 8h, 12h+) — one pair per horizon per settlement period |
| `operational_planning_margin_requirement` | the operational planning margin requirement (OPMR) — the amount of generation exceeding the peak demand forecast needed to meet the day-ahead reserve requirement, published per delivery day (daily… |
| `surplus_forecast_daily` | forecast Generating Plant Operating Surplus (available generation capacity minus expected demand) for daily horizons 2-14 days ahead, in MW — OCNMFD dataset |
| `year_ahead_forecast_margin_a70` | forecast margin (available generation capacity − forecast demand) for the year ahead, per area — the surplus or deficit the TSO expects |
| Definition | Measures |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `available_installed_capacity` | Available Installed Capacity (AIC / EAK) per production type and hour — the installed capacity each licensed unit declares as actually available for the delivery hour, after outages and deratings |
| `output_usable_capacity_forecast` | forecast of output-usable generation capacity per fuel type (and per interconnector) for future delivery days or weeks — the capacity a technology can physically deliver, distinct from both namepla… |
| `unit_available_capacity_remit` | the capacity of one named generation unit that remains AVAILABLE during a declared outage, as change-points: the declared value from the outage's start, the unit's normal capacity again from its en… |
| `unit_output_usable_capacity` | forecast output-usable capacity of one named BM generation unit for a future delivery week, expressed in MW — the capacity Elexon estimates the unit can actually deliver, distinct from its nameplat… |
| `unit_output_usable_capacity_daily` | per-BM-unit output-usable capacity forecast, published daily for 2–14 calendar days ahead; each row is one BM unit × one forecast day at one publication revision, with outputUsable in MW, fuelType… |
| Definition | Measures |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ember_installed_capacity` | installed generating capacity of one country at a month, in GW, per Ember series (solar and wind among them), as compiled by Ember |
| `ember_installed_capacity_per_capita` | installed generating capacity per inhabitant of one country at a month, in watts per person, per Ember series, as Ember publishes it |
| `installed_capacity_per_type` | installed generation capacity per production type, per calendar year |
| `installed_capacity_per_unit_a71` | installed capacity of one NAMED generation unit, per calendar year — the unit-level view behind the per-type aggregate |
| `wind_forecast_capacity_used` | total wind power production capacity (MW) that a system operator's own wind forecast is scaled against, published alongside that forecast — the operational capacity figure inside the forecast model… |
| Definition | Measures |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `procured_balancing_capacity` | reserve capacity a TSO has CONTRACTED for a delivery period, per reserve product (FCR / aFRR / mFRR) — megawatts held available, not megawatts delivered |
| `reserve_capacity_requirement` | the reserve capacity a system operator REQUIRES or demands ahead of procurement, per reserve product and direction — the demand side of the reserve market, before any bids or contracts (merged 2026… |
| Definition | Measures |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `constraint_limit_weekly_forecast` | forecast MW constraint limit per named transmission boundary (DRESHEX1, ESTEX, FLOWSTH, GM+SNOW5A, HARSPNBLY, NKILGRMO, SCOTEX, SEIMPPR2, SSE+GRM, SSEN-S, SSE-SP2, SSHARN3), at weekly resolution, s… |
| `day_ahead_constraint_flow_and_limit` | day-ahead snapshot of forecast flow (MW) and limit (MW) per GB constraint boundary group (ESTEX, FLOWSTH, SCOTEX, SSHARN3, etc.), at half-hourly settlement-period resolution, published daily |
| `permanent_allocation_limitations_hvdc` | permanent allocation limitations on HVDC interconnectors, per direction and per HVDC resource — the capacity limits that constrain allocation on specific HVDC links under standing (permanent) arran… |
| `stable_export_limit` | the minimum stable operating level at which a GB BM unit can export power to the transmission system, in MW — the Stable Export Limit (SEL) |
| `stable_import_limit` | the minimum stable operating level at which a GB BM unit can import power FROM the transmission system, in MW — the Stable Import Limit (SIL) |
| Definition | Measures |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `maximum_delivery_bid` | the maximum volume (MW, signed negative) a GB BM unit can bid to reduce output in the balancing mechanism — the MDB (Maximum Delivery Bid) value per unit per settlement period, as a ramped levelFro… |
| `maximum_delivery_offer` | the maximum volume (MW) a GB BM unit can offer as a bid in the balancing mechanism — the MDO (Maximum Delivery Offer) value per unit per settlement period, as a ramped levelFrom/levelTo pair |
| `maximum_delivery_period` | the maximum number of consecutive settlement periods for which a GB BM unit can deliver at its maximum delivery volume, expressed as a number of settlement periods — the Maximum Delivery Period (MDP) |
| `maximum_delivery_volume` | the maximum volume a GB BM unit can deliver in a settlement period, in MW — the Maximum Delivery Volume (MDV) |
| `minimum_non_zero_time` | the minimum time a GB BM unit must spend at non-zero output before it can return to zero, in minutes — the Minimum Non-Zero Time (MNZT) |
| `minimum_zero_time` | the minimum time a GB BM unit must spend at zero output before it can change to a non-zero output, in minutes — the Minimum Zero Time (MZT) |
| `notice_to_deliver_bids` | the minimum notice period a GB BM unit requires before delivering a bid (reducing output), in minutes — the Notice to Deliver Bids (NTB) |
| `notice_to_deliver_offers` | the minimum notice period a GB BM unit requires before delivering an offer (increasing output), in minutes — the Notice to Deliver Offers (NTO) |
| `notice_to_deviate_from_zero` | the minimum notice period a GB BM unit requires before deviating from zero output, in minutes — the Notice to Deviate from Zero (NDZ) |
| `unit_maximum_export_limit` | the maximum export a GB BM unit declares it is able to deliver — the BSC's availability signal, per unit per settlement period |
| `unit_maximum_import_limit` | the maximum import a GB BM unit declares it is able to accept — the import-direction twin of unit\_maximum\_export\_limit, per unit per settlement period |
| Definition | Measures |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `a65_load_forecast` | the forecast ENVELOPE of total load for a future horizon: a MINIMUM and a MAXIMUM curve, published as the pair of ENTSO-E businessTypes A60 "Minimum possible" and A61 "Maximum possible", by TSOs un… |
| `admie_week_ahead_load_forecast` | IPTO's week-ahead total load forecast for the Greek interconnected system: a single point-value curve (not a min/max envelope) at the horizon's own published resolution — `ISPWeekAheadLoadForecast`… |
| `day_ahead_generation_unit_consumption_forecast` | the aggregated day-ahead forecast of electricity consumed by generation assets themselves — pumped-storage pumping and plant self-supply — for each interval of the next delivery day, per area. It i… |
| `day_ahead_total_load_forecast` | forecast total load per area for the next delivery day — the day-ahead forecast sibling of total\_load, published under the same documentType A65 with processType A01 (Day-ahead) instead of A16 (Rea… |
| `demand_forecast_performance` | the GB day-ahead half-hourly national demand forecast published alongside the matched outturn for the same settlement period, with the absolute error (MW) and absolute percentage error (APE) betwee… |
| `distribution_company_demand_forecast` | yearly low/base/high demand forecast per Turkish distribution company, in MWh — three scenarios (low, base, high) per forecast year, published as a snapshot covering approximately 10 years ahead |
| `five_year_plan_forecast` | PSE's five-year coordinated plan forecast with hourly grid demand, required reserve, available capacity, wind/PV forecast, and planned exchange data |
| `forecast_daily_peak_demand` | the single highest forecast settlement-period demand value in a calendar day, derived from the Transmission System Demand Forecast (TSDF) — the forecast counterpart of daily\_demand\_extremes |
| `gross_load_forecast` | GROSS-boundary load forecast of a zone at any published horizon (the multi-horizon gross canonical; merged 2026-08-31: MAVIR's weekly/monthly/yearly reports and ESO Bulgaria's short-term forecast) |
| `long_term_weekly_demand_forecast` | 2–52 week ahead forecast of GB weekly peak and minimum demand, published by NESO as one row per ESI week with the forecast peak Transmission System Demand (TSD), the weekly minimum, and separate da… |
| `national_demand_forecast` | forecast of GB Initial National Demand for future settlement periods, at half-hourly (cardinal-point) resolution; same quantity as initial\_national\_demand\_outturn but for a delivery window that has… |
| `peak_hours_usage_forecast` | PSE's peak-hours usage forecast indicator, published per hourly slot with versioned updates (valid\_from\_ts/valid\_to\_ts, is\_active); indicates whether the hour is forecast as a peak period |
| `residual_load_forecast` | forecast residual load (total load minus generation from wind and solar) for future delivery intervals; distinct from forecast total load |
| `restoration_zone_demand_forecast` | forecast demand that could be restored within 60 minutes and within 100 minutes per GB restoration zone (region × GSP group), submitted by distribution network operators for each settlement date |
| `total_load_forecast` | forecast total load for future delivery intervals (most-recent, day-ahead and week-ahead horizons, with confidence bands), distinct from realised load |
| `transmission_system_demand_forecast` | forecast of GB Transmission System Demand for future settlement periods, at half-hourly resolution; the forecast version of transmission\_boundary\_demand — INCLUDES interconnector flows and demand f… |
| Definition | Measures |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `transmission_loss_factor` | the transmission loss coefficient applied in settlement for a period — the factor by which metered withdrawals are grossed up to cover losses on the transmission network, published per settlement v… |
| `transmission_losses` | electrical energy lost in the transmission grid (technical losses in the high-voltage network), expressed as daily energy and as a percentage of total demand — published by REE as a single daily va… |
| Definition | Measures |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `actual_consumption_per_unit_a73` | actual electricity consumption BY one NAMED generation unit — the outBiddingZone\_Domain TimeSeries that ENTSO-E A73 publishes beside the machine's generation block: pumping drawn from the grid by a… |
| `esios_p48_final_programme_withdrawal` | the FINAL programmed energy of one Spanish programming unit (UP) that withdraws from the system — the `UPSalida` series of REE's P48 closure (p48cierre, e·sios archive 107): suppliers, direct marke… |
| Definition | Measures |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `day_ahead_consumption_plan` | the TSO's own published plan for system consumption over a delivery day — the planned (scheduled) load the operator compares its realised load against on its public dashboard, at the publisher's ow… |
| Definition | Measures |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `actual_consumption_per_type` | actual electricity consumption BY generation assets, per production type — the outBiddingZone\_Domain half of ENTSO-E document A75 ("Actual Generation and Consumption per Type") — plant self-consump… |
| `consumption_estimate` | real-time consumption estimate per bidding area combining metered data and balance-responsible-party forecasts, published hourly as part of SVK's control-room overview |
| `demand_including_self_consumption` | Spanish system demand with behind-the-meter self-consumption ("autoconsumo") added back in, published on the same five-minute grid as the demand and scheduled-demand curves beside it |
| `eso_load_and_forecast` | ESO's own system load as one date-named series per civil day (24 hourly values): realized load for elapsed dates and load forecast for future dates, served together in one payload with no per-serie… |
| `gross_system_load` | realised GROSS system load of a zone — load before netting off the terms total\_load subtracts — from any publisher carrying the zone's own gross figure (merged 2026-08-31: MAVIR "brutto teny", ESO… |
| `initial_national_demand_outturn` | initial national demand derived from metered generation, including transmission losses but excluding station load, pumped-storage demand, and interconnector exports |
| `market_load` | system load served through the competitive wholesale electricity market, excluding on-site self-consumption and contracted off-market consumption — the demand actually transacted on the wholesale m… |
| `operational_consumption` | total system consumption in Norway as reported by Statnett's driftsdata operational data; the inclusion boundary (grid losses, station load, pumped-storage demand) is not documented |
| `peak_hours_total_demand` | total power demand during peak hours, published per hourly slot by PSE alongside the usage forecast indicator, with versioned updates |
| `pumped_storage_pumping_load` | actual pumped-storage pumping demand as a load component — the power consumed by pumped-storage plants for pumping, separate from the total load figure |
| `system_consumption` | Moldovan system consumption ("Consumul") in MW at 15-minute resolution as published by the TSO's own operative archive |
| `total_load` | net generation − exports + imports − absorbed (stored) energy |
| `transmission_boundary_demand` | initial transmission-system demand at the transmission boundary, including transmission losses, station load, pumped-storage demand, and interconnector demand, but excluding demand served by embedd… |
| Definition | Measures |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `eligible_consumer_consumption_quantity` | monthly consumption quantity of eligible versus non-eligible consumers, split per subscriber profile group (lighting, residential, industrial, commercial, agricultural irrigation …) |
| `eligible_consumer_withdrawal_quantity` | settlement-based withdrawal quantity of ELIGIBLE consumers only (serbest tüketici, "ST-UECM") in a bidding zone, per settlement period — the subset of settlement withdrawal supplied on a free-marke… |
| `net_commercial_settlement_load` | net Hungarian system load from COMMERCIAL SETTLEMENT METERING ("nettó kereskedelmi elszámolási mérés"), published on MAVIR's system\_load chart alongside the operational (SCADA) net actual, at the s… |
| `settlement_net_consumption` | settlement-based net consumption per balance responsible party — metered (E02) + profiled (E01) + flex, aggregated per MBA |
| `withdrawal_under_supply_liability` | withdrawal quantity supplied under the regulated supply liability (görevli tedarik) in a bidding zone, per invoice period — consumption of customers who have not moved to a free-market supplier |
| Definition | Measures |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `announced_meter_count` | the total meter (metering point) count announced by EPIAS per settlement period in Turkey — one nationwide count per month |
| `eligible_consumer_meter_count` | monthly eligible customer (meter) count per subscriber profile group in Turkey — the number of meters using eligible consumer rights (stAdedi) and not using them (stOlmayanAboneAdedi), per profile… |
| `ember_demand` | electricity demand of one country in one calendar year, in TWh, as compiled by Ember |
| `ember_demand_per_capita` | electricity demand per inhabitant of one country in one calendar year, in kWh per person, as Ember publishes it |
| `retroactive_adjustment_meter_count` | the number of metering points subject to a retroactive settlement adjustment in a settlement period, per distribution company and subscriber profile group, split by meter reading type |
| Definition | Measures |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `absolute_co2_emissions` | absolute CO2 emissions from electricity generation — mass or mass-rate, any zone, cadence or fuel split (merged 2026-08-31: MAVIR, REE's instantaneous snapshot, EirGrid's tCO2/h rate, EDF SEI and T… |
| `ember_power_sector_emissions` | CO2 emitted by the power sector of one country in one calendar year, in million tonnes CO2 (MtCO2), per Ember series (the emitting fuels and Ember's aggregates of them) |
| `ember_power_sector_emissions_share` | the share of one Ember series in a country's power-sector CO2 emissions for one calendar year, in percent, as Ember publishes it beside ember\_power\_sector\_emissions |
| Definition | Measures |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `consumption_carbon_intensity` | CO2 intensity of electricity CONSUMED in a zone or sub-zonal area, in gCO2/kWh — the generation-mix intensity adjusted for the carbon content of imports and exports (merged 2026-08-31: Elia, CEPS,… |
| `ember_carbon_intensity` | the average CO2 intensity of one country's electricity generation in one calendar year, in grams CO2 per kWh, as Ember publishes it |
| `production_carbon_intensity` | CO2 intensity of electricity GENERATED in a zone, in gCO2/kWh — emissions attributed to domestic production divided by that production (merged 2026-08-31: Elia, RTE eCO2mix, EirGrid, Fingrid) |
| Definition | Measures |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `netted_and_exchanged_balancing_volumes` | the balancing energy volumes netted and exchanged between two LFC areas across one border via the European platforms (imbalance netting, mFRR, aFRR), per direction and market time unit |
| `netted_and_exchanged_volumes_b17` | the balancing energy volumes an LFC area netted and exchanged with the European platforms (imbalance netting, mFRR, aFRR), per direction and market time unit, for the area as a whole |
| Definition | Measures |
| --------------- | -------------------------------------------------------------------------------- |
| `physical_flow` | realised physical cross-border flow per directed border, net = forward − reverse |
| Definition | Measures |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `aggregate_net_position` | a zone's total net exchange with all its neighbours summed into one figure, signed by the publisher's own import/export convention |
| `commercial_exchange_schedule` | scheduled commercial cross-border exchange, distinct from the physical power flow over interconnectors |
| `day_ahead_net_position` | the realised net position of a bidding zone after day-ahead market coupling (SDAC), published per hub by the flow-based market coupling operator; one signed value per MTU per hub |
| `planned_net_interchange` | the PLANNED net interchange of a control area — the scheduled total exchange with all neighbours summed into one signed figure, published per market time unit beside the realised value |
| Definition | Measures |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `gross_import_export_volume` | total energy imported into / exported from a zone over an interval, published as SEPARATE gross directions rather than a net figure |
| Definition | Measures |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `continuous_offered_capacity` | cross-border transfer capacity OFFERED through continuous intraday allocation, per direction — the capacity released to continuous trading after the day-ahead explicit auction |
| `explicit_offered_capacity` | cross-border transfer capacity OFFERED in explicit allocation auctions, per direction — the capacity made available to market participants through explicit bidding |
| `explicit_used_capacity` | cross-border transfer capacity ACTUALLY USED following explicit allocation — the capacity nominated and taken up by market participants, per direction |
| `long_term_allocated_capacity` | cross-border transfer capacity ALLOCATED through long-term transmission rights (LTTR) auctions, per directional border — the capacity awarded to market participants for yearly, seasonal or monthly… |
| `long_term_offered_capacity` | transmission capacity offered through long-term auctions for year, quarter, and month product horizons, per directed border — the capacity made available to market participants through long-term al… |
| `offered_transfer_capacity` | transfer capacity offered to the market in the implicit day-ahead allocation per interconnection and direction |
| `total_capacity_already_allocated` | total cross-border transfer capacity already allocated to market participants per interconnection and direction — reflecting allocations that have been made and confirmed for the delivery period |
| `total_nominated_capacity` | total capacity nominated by market participants per interconnection and direction — the capacity actually used after allocation |
| Definition | Measures |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `congestion_auction_revenue` | the revenue an explicit capacity auction raised on a border, per direction and market time unit, in the auction currency |
| `explicit_used_capacity_price` | the price attached to cross-border transfer capacity actually USED following explicit allocation, per direction and market time unit — the second value element of the same A25/businessType B05 Poin… |
| Definition | Measures |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `available_transfer_capacity` | available transfer capacity (ATC) per interconnection and direction — the capacity still free after prior allocations |
| `day_ahead_ntc` | forecasted day-ahead net transfer capacity per direction — each direction is its own series, never netted |
| `interconnection_line_capacity` | the TOTAL and the still-AVAILABLE transfer capacity of an interconnection, published per directed border by the transmission capacity allocation tool — two series per direction |
| `intraday_transfer_capacity` | cross-border transfer capacity offered in the INTRADAY timeframe on a DC interconnector, per directed border |
| `month_ahead_ntc_forecast` | month-ahead NTC forecast per border and direction — the NTC component of a monthly auction publication. Elia publishes it at daily resolution with the capacity for auction decomposed separately; EN… |
| `operated_transfer_capacity` | net transfer capacity (NTC) per interconnection and direction as operated, at the publisher's own cadence — the capacity the TSO states for the link, before allocation |
| `week_ahead_ntc_forecast` | week-ahead NTC forecast per border and direction, published by Elia at daily resolution for the coming week — the best available NTC forecast updated weekly from the previous week's data |
| `year_ahead_ntc_forecast` | year-ahead forecast net transfer capacity per border and direction, published at monthly granularity for the coming delivery year |
| Definition | Measures |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `synchronous_area_frequency` | electrical frequency of a synchronous area at the source's measurement location, at whatever resolution or aggregation the source publishes — instantaneous samples, hourly mean/RMS-deviation rows,… |
| Definition | Measures |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `afrr_activation_price` | price of activated aFRR balancing energy — marginal, volume- weighted, local-selection and CBMP publications; direction, selection channel and resolution are axes. Product split ruled 2026-08-31. |
| `balancing_activation_price` | the price paid for balancing energy actually ACTIVATED in a control area, per reserve product (FCR / aFRR / mFRR / RR) |
| `balancing_capacity_price` | the price paid for RESERVING balancing capacity, per reserve product and delivery period — a capacity payment in EUR/MW |
| `value_of_avoided_activation` | Value of Avoided Activation (VoAA) in EUR/MWh — the counterfactual price that would have been paid for balancing energy if the most expensive activated bid had not been needed, per Nordic bidding z… |
| Definition | Measures |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `guarantee_of_origin_match_price_range` | the minimum and maximum price at which guarantee-of-origin documents were MATCHED in the organised GO market on a trade date, per renewable resource type |
| `guarantee_of_origin_trade_value` | the monetary turnover of the organised guarantee-of-origin market on a trade date, per renewable resource type, in the local currency and in USD/EUR |
| `guarantee_of_origin_weighted_average_price` | the volume-weighted average price of guarantee-of-origin documents matched in the organised GO market on a trade date, per renewable resource type, quoted in the local currency and in USD/EUR |
| Definition | Measures |
| ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `day_ahead_auction_price` | day-ahead auction clearing price per bidding zone |
| `day_ahead_block_bid_volume` | volume of BLOCK purchase bids in the day-ahead auction per delivery hour, split into the matched and unmatched parts |
| `day_ahead_block_offer_volume` | volume of BLOCK sales offers in the day-ahead auction per delivery hour, split into the matched and unmatched parts |
| `day_ahead_flexible_bid_volume` | volume of FLEXIBLE purchase orders in the day-ahead auction per delivery day — total, matched and unmatched. A flexible order names a duration but not the hour, and the auction chooses the hour |
| `day_ahead_flexible_offer_volume` | volume of FLEXIBLE sales orders in the day-ahead auction per delivery day — total, matched and unmatched |
| `day_ahead_market_trade_value` | the monetary trade value (turnover) of the day-ahead market per hour — matched quantity valued at the clearing price, in local currency |
| `day_ahead_matched_flexible_offer_volume` | the matched volume of flexible day-ahead orders allocated to each delivery HOUR, buy and sell side — where day\_ahead\_flexible\_bid\_volume is a daily total, this is the hour the auction placed it in |
| `day_ahead_price_independent_bid_volume` | volume of PRICE-INDEPENDENT purchase bids in the day-ahead auction per delivery hour — demand submitted at the price cap and therefore matched at any clearing price |
| `day_ahead_price_independent_offer_volume` | volume of PRICE-INDEPENDENT sales offers in the day-ahead auction per delivery hour — supply submitted at the price floor and therefore matched at any clearing price |
| `day_ahead_side_payments` | day-ahead market side payments per delivery day, in local currency, split by origin (bids, offers, rounding) plus their total — the compensation paid out when the uniform clearing price does not fu… |
| `day_ahead_submitted_bid_volume` | total volume of PURCHASE bids submitted into the day-ahead auction for each delivery hour, read at the lowest price step of the demand curve |
| `day_ahead_submitted_offer_volume` | total volume of SALES offers submitted into the day-ahead auction for each delivery hour, read at the highest price step of the supply curve |
| `day_ahead_traded_volume` | day-ahead market traded volume per bidding zone, published as SEPARATE buy and sell series per area — the energy bought and sold in the day-ahead auction |
| `short_term_market_index_price` | price and traded volume reported by each appointed GB market-index data provider for a settlement period; not a day-ahead auction price |
| Definition | Measures |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `bilateral_contract_purchase_quantity` | the energy quantity PURCHASED through bilateral (over-the-counter) contracts and notified to the settlement system, per settlement period — aggregated for the zone, or for one named market participant |
| `bilateral_contract_sale_quantity` | the energy quantity SOLD through bilateral (over-the-counter) contracts and notified to the settlement system, per settlement period — aggregated for the zone, or for one named market participant |
| `regulated_bilateral_contract_amount` | the monthly contracted energy amount of the REGULATED bilateral contracts between the state generation company and the authorised retail suppliers — the administratively-set wholesale volume behind… |
| Definition | Measures |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `imbalance_price` | the imbalance settlement prices of a CONTROL AREA per settlement period (ENTSO-E A85, 17.1.G), one series per `imbalance_Price.category` of the code list: A04 excess balance (the price applied to a… |
| `imbalance_settlement_amount` | the MONETARY amount settled for imbalance in a settlement period, split into the credit paid to positively-imbalanced parties and the debit charged to negatively-imbalanced ones — currency, not MWh |
| `imbalance_settlement_price` | indicative system buy and sell price used for GB imbalance settlement |
| `incentivising_component` | the Incentivising Component (IC) of the Nordic imbalance settlement price per bidding zone, in EUR/MWh — the component that incentivises balance responsible parties to stay in balance, as defined i… |
| `maximum_settlement_price` | the administratively-set CEILING price applied in imbalance settlement for a period, published with the market-price cap it was derived from and the per-fuel reference costs (natural gas, imported… |
| `settlement_market_depth` | GB balancing-settlement market depth per settlement period: indicated imbalance, total bid/offer volumes, total accepted bid/offer volumes, and priced (DISEBSP) accepted bid/offer volumes — an aggr… |
| `single_price_imbalance_settlement` | settlement price applied to a balance responsible party's imbalance under a single-price, single-position model |
| Definition | Measures |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `intraday_auction_clearing_price` | the clearing price of a single intraday auction session (IDA1, IDA2 or IDA3) for a bidding zone, per delivery period, in EUR/MWh |
| `intraday_continuous_price_statistics` | the quantity-weighted average price of all intraday continuous trades for one delivery hour |
| Definition | Measures |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `intermittent_market_reference_price` | the reference price intermittent CfD generators are settled against (IMRP), published per settlement period by the LCCC |
| `renewables_support_dam_offer_quantity` | the quantity the national load dispatch centre OFFERS into the day-ahead market on behalf of the renewables-support-mechanism portfolio, per settlement period |
| `renewables_support_licensed_generation_cost` | the feed-in cost of LICENSED plants in a renewables support mechanism per settlement period and per renewable resource — generation multiplied by the administratively-set feed-in tariff |
| `renewables_support_mechanism_income` | the income side of a renewables support mechanism per settlement period and per renewable resource — what the scheme received back for the energy it supported |
| `renewables_support_portfolio_imbalance_cost` | the monetary cost charged to the renewables-support-mechanism portfolio for its own imbalance in a settlement period |
| `renewables_support_portfolio_income` | the income the renewables-support-mechanism portfolio earned from selling its generation into the spot market, per settlement period |
| `renewables_support_total_cost` | the total monthly cost of a renewables support mechanism — licensed plus unlicensed feed-in cost, decomposed per renewable resource |
| `renewables_support_unit_cost` | the UNIT cost of a renewables support mechanism for a settlement month — the per-MWh amount every withdrawing party pays towards the scheme, published per settlement version alongside the reference… |
| `renewables_support_unlicensed_generation_cost` | the feed-in cost of UNLICENSED (distribution-connected) plants in a renewables support mechanism, per invoice period and per renewable resource |
| Definition | Measures |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `indicative_balancing_cashflow` | indicative cashflow amounts derived from settlement calculations for GB BM units, expressed as GBP per settlement period per bid/offer pair; the financial settlement amount resulting from accepted… |
| `retroactive_adjustment_amount` | the total monetary retroactive settlement adjustment for a settlement period — credit, debit and net amount, published per settlement version |
| `settlement_zero_balance_adjustment` | the monthly zero-balance adjustment of an imbalance settlement scheme — the residual that makes the settlement sum to zero, decomposed into its components (up/down regulation, manual instructions,… |
| Definition | Measures |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `monthly_supply_cost_index` | a monthly index (reference 100) of the cost of supplying electricity to one main tariff group, computed by the publisher from the day-ahead clearing price, the negative imbalance price, the renewab… |
| `regulated_retail_tariff_pvpc` | Precio Voluntario para el Pequeño Consumidor — Spain's regulated retail electricity tariff for small consumers, built from the wholesale spot price plus regulated network, capacity and system-cost… |
| Definition | Measures |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `embedded_generation_forecast` | forecast generation from EMBEDDED (distribution-connected) wind and solar installations per settlement period, published as separate wind and solar MW values alongside the estimated installed capac… |
| `unlicensed_generation_amount` | generation fed in by UNLICENSED (distribution-connected, below the licence-exemption threshold) plants, per settlement period and per renewable resource |
| Definition | Measures |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `combined_wind_and_solar_generation_forecast` | the SUM of wind and solar generation forecast for an area, published as ONE number by an upstream that does not split it (SMARD's `solar_and_wind` day-ahead and intraday series) |
| `day_ahead_res_generation_forecast` | IPTO's day-ahead renewable (RES) generation forecast for the Greek interconnected system, published for the delivery day by the ISP1 (evening before, \~18:35 Europe/Athens), ISP2 (after day-ahead ma… |
| `day_ahead_total_generation_forecast` | the AGGREGATED forecast of net generation for the day ahead, per area — the TSO's published day-ahead generation schedule as a single total, with no breakdown by production type. It is the \`inBiddi… |
| `generation_forecast_per_type` | forecast net generation per production type — solar, wind (onshore/offshore), load, or aggregate wind — at current, intraday, day-ahead or week-ahead horizon |
| `indicated_margin_forecast` | day-ahead indicated margin forecast — the surplus of indicated generation over indicated demand, published alongside the other three indicated quantities as part of a single day-ahead forecast publ… |
| `margin_forecast` | 2-14 day ahead margin forecast for the GB system — the operational capacity margin (surplus of available generation over expected demand) for each forecast day, published daily with a 2-14 day horizon |
| `net_export_forecast` | forecast net export (positive) / net import (negative) for future delivery intervals, published alongside a participant-plan production forecast — minted 2026-09-21 (Davide, forecast-vintages task)… |
| `netztransparenz_extrapolated_generation` | the German TSOs' quarter-hourly EXTRAPOLATION (Hochrechnung) of actual wind or solar feed-in, published per control area |
| `production_forecast` | participant-plan production forecasts per fuel-ish category, distinct from actual realised generation |
| `production_plan_forecast` | forecast total electricity production in Finland based on production plans reported by balance responsible parties; distinct from realised generation. Two datasets are used: 241 (updated every 15 m… |
| `solar_generation_forecast` | forecast solar generation for future delivery intervals, at any published horizon (the multi-horizon solar canonical) — absorbed 2026-08-31: elia solar\_production\_forecast (P10/P90 bands are variab… |
| `total_generation_forecast` | forecast total generation for future delivery intervals (day-ahead), distinct from realised generation — absorbed 2026-08-31: the bmrs trio day\_ahead\_aggregated\_generation\_forecast / indicated\_gene… |
| `wind_forecast_operational_metered` | NESO's 14-day ahead wind forecast per SCADA-metered windfarm, at half-hourly settlement-period resolution — metered (SCADA) wind farms only, not all wind BMUs |
| `wind_generation_forecast` | forecast wind generation for future delivery intervals, at any published horizon or rolling ladder (the multi-horizon wind canonical) — absorbed 2026-08-31: elia wind\_production\_forecast (P10/P90 b… |
| Definition | Measures |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `guarantee_of_origin_bid_ask_quantity` | the bid and ask document quantities submitted to the organised guarantee-of-origin market on a trade date, per renewable resource type — two series, buy-side and sell-side |
| `guarantee_of_origin_bilateral_transfer_quantity` | the number of guarantee-of-origin documents transferred BILATERALLY (outside the organised market) on a trade date, per renewable resource type |
| `guarantee_of_origin_cancelled_quantity` | the number of guarantee-of-origin documents CANCELLED (redeemed for disclosure) on a trade date, per renewable resource type — the act that retires a certificate against a supplier's disclosure claim |
| `guarantee_of_origin_expired_quantity` | the number of guarantee-of-origin documents that EXPIRED unused on a trade date, per renewable resource type — certificates that reached the end of their validity window without being cancelled |
| `guarantee_of_origin_issued_quantity` | the number of guarantee-of-origin documents ISSUED (exported to the registry) for a trade date, per renewable resource type — one document per MWh of certified renewable generation |
| `guarantee_of_origin_matched_quantity` | the number of guarantee-of-origin documents MATCHED (traded) in the organised GO market on a trade date, per renewable resource type |
| `guarantee_of_origin_withdrawn_quantity` | the number of guarantee-of-origin documents WITHDRAWN from the registry on a trade date, per renewable resource type — documents pulled back by the registry operator, typically after a system or me… |
| Definition | Measures |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ember_generation_share` | the share of one Ember series in a country's total electricity generation for one calendar year, in percent, as Ember publishes it beside ember\_generation |
| `ember_monthly_generation_share` | the share of one Ember series in a country's total electricity generation for one calendar month, in percent, as Ember publishes it beside ember\_monthly\_generation |
| `generation_mix_share_by_fuel` | the percentage share each fuel contributed to total electricity generation over a stated period, one value per fuel, the values summing to \~100 |
| `generation_split_by_emissions` | total generation split into CO₂-emitting and emission-free portions, each with MW and percentage share — the "Without CO2 eq. emissions" and "With CO2 eq. emissions" series from REE's generation ev… |
| Definition | Measures |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `actual_generation_per_unit_a73` | realised net generation of one NAMED generation unit, hourly — the unit-level view behind the per-type aggregate |
| `esios_p48_final_programme_injection` | the FINAL programmed energy of one Spanish programming unit (UP) that injects into the system — REE's P48 closure (p48cierre, e·sios archive 107), the operating schedule after every market session… |
| `unit_physical_notification` | the output one GB BM unit has notified it intends to deliver in a settlement period, as a levelFrom/levelTo ramp rather than a flat value |
| `unit_quiescent_notification` | the MW levels to be deducted from the Physical Notification of a GB BM unit to determine a resultant operating level — the "quiescent" output before balancing actions modify it |
| `wind_generation_forecast_per_unit` | forecast wind generation for one NAMED Balancing Mechanism Unit (BMU), per settlement period, with that unit's installed capacity — the per-generator decomposition of the day-ahead wind forecast |
| Definition | Measures |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `final_daily_production_program` | the Final Daily Production Program (KGÜP / FDPP) per production type — the generation each licensed unit declares it will produce in each hour of the delivery day, as of day-ahead market gate closure |
| `mavir_power_plant_generation_plan` | MAVIR's own gross and net generation PLAN (schedule-based) for Hungarian power plants specifically, published on chart 4401 at 15-min resolution — "Bruttó terv erőművi termelés" (name gross) / "Net… |
| `planned_generation` | planned (scheduled) gross generation aggregated for a zone, distinct from actual realised generation — the operator's day-ahead or longer-horizon generation plan |
| `production_plan` | the PLANNED Moldovan gross production ("Planul producţiei") in MW for the same 15-minute periods as the realised figure |
| `svk_solar_production_plan` | solar generation production plan per bidding area submitted by market participants (productionPlanResource field = "SOLENERGI"), including upstream registrationTime; distinct from measured or forec… |
| Definition | Measures |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `actual_generation_per_type` | actual net generation per production type (psrType), per area — from any publisher carrying the same numbers (ruling 2026-08-31, same-number-merge: absorbed litgrid\_gamyba\_101..106, eex\_renewables\_… |
| `actual_or_estimated_generation_per_type` | actual or estimated wind and solar generation per PSR type (Wind Onshore, Wind Offshore, Solar) per settlement period; the businessType field distinguishes actual generation from Estimated values,… |
| `actual_total_generation` | source-reported total realised electricity generation for a zone or sub-zonal area (areas are targets), without a production-type breakdown — absorbed 2026-08-31: tsoc\_total\_transmission\_generation… |
| `eco2mix_generation_mix` | realised electricity generation of France, or of a French administrative region, broken down by production type at 15-minute resolution as published in RTE's éCO2mix series — nuclear, thermal (with… |
| `gross_production` | total GROSS Moldovan electricity production ("Producţia") in MW at 15-minute resolution, as published by the TSO's own operative archive |
| `gross_production_per_native_category` | gross Moldovan production split into the operator's own three native categories at 15-minute resolution — CET/CTE (combined-heat-and-power and condensing thermal plant), CHE (hydro), SRE (renewable… |
| `half_hourly_generation_outturn_by_fuel` | half-hour average GB generation outturn grouped by Elexon fuel type |
| `mavir_gross_power_plant_generation` | gross realised electricity generation aggregated across Hungarian power plants ("Bruttó tény erőművi termelés"), before deducting plant self-consumption — MAVIR chart 4401, 15-min resolution |
| `monitored_capacity` | installed wind/solar capacity (MW) Elia actually monitors and includes in its production estimation/forecast model for a region, published alongside the production and forecast columns on the same… |
| `production_per_plant_class` | 5-minute realtime production in Energinet's operational categories (plants \<100 MW, ≥100 MW, offshore wind, onshore wind, solar) per Danish price area; categories describe plant class, not fuel |
| `published_load_factor` | the ratio (%) of realtime/measured production to monitoredcapacity for the same region and timestamp, as Elia itself computes and publishes it (not derived here) — minted 2026-09-21 (forecast- vint… |
| `realtime_generation_per_category` | real-time (3-minute) measured electricity production of a TSO's area per production category, read from its operation control system rather than from settlement metering — Fingrid publishes wind, n… |
| `solar_production_realtime` | measured and upscaled photovoltaic generation on the Belgian grid at 15-min resolution, aggregated by region; an estimation/nowcast, not per-installation metering |
| `wind_power_generation` | actual wind power generation for a zone, distinct from forecast wind generation |
| `wind_production_realtime` | measured and upscaled wind power generation on the Belgian grid at 15-min resolution, aggregated by region, offshore/onshore, and grid connection type; an estimation/nowcast, not per-turbine metering |
| Definition | Measures |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `settlement_based_final_generation_plan` | the Settlement-Based Final Generation Plan (KUDÜP / SBFGP) per production type — the last generation declaration each unit makes after intraday market gate closure, which is what imbalance is settl… |
| `settlement_net_production` | settlement-metered net production per zone or settlement area, whatever the settlement system (eSett MBA, EPIAS, Energinet Datahub, SEM jurisdictions, MAVIR elszamolasi, Elhub municipalities) — abs… |
| Definition | Measures |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ember_generation` | electricity generated in one country in one calendar year, in TWh, per Ember series: the fuels (Coal, Gas, Nuclear, Hydro, Wind, Solar, Bioenergy, Other fossil, Other renewables) and Ember's own ag… |
| `ember_monthly_generation` | electricity generated in one country in one calendar month, in TWh, per Ember series: the fuels and Ember's own aggregates of them, plus Demand and Net imports, as in ember\_generation |
| Definition | Measures |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `netztransparenz_eeg_marketing_forecast` | the marketing forecast (Vermarktungsprognose) the German TSOs base their EEG sales on, per control area and quarter-hour, in MW — published per technology group (solar, wind, other) |
| `netztransparenz_feedin_forecast_difference` | the difference between successive EEG feed-in forecasts per control area and quarter-hour, in MW — the forecast revision the TSOs had to trade out |
| `renewables_support_generation_forecast` | the generation FORECAST that plants under a feed-in-tariff mechanism report to the national load dispatch centre, per settlement period and per renewable resource |
| `renewables_support_licensed_generation` | real-time generation of the LICENSED plants enrolled in a renewables support mechanism, per renewable resource (wind, geothermal, reservoir / run-of-river / canal hydro, landfill gas, biogas, solar… |
| `renewables_support_licensed_injection` | the SETTLEMENT-based injection quantity of the licensed plants enrolled in a renewables support mechanism, per settlement period and per renewable resource |
| Definition | Measures |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `charging_and_discharging_power` | separately published charging and discharging power by storage technology, retained as separate directions rather than netted |
| Definition | Measures |
| ------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `reservoir_filling` | energy stored in an area's water reservoirs and hydro storage plants, aggregated over the area and published weekly |
| Definition | Measures |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `normal_and_actual_daily_temperature` | the pair of daily temperatures a market operator publishes as the weather input to its load-profile correction — the long-run NORMAL temperature expected for that calendar day and the temperature a… |
| `outside_air_temperature` | outside air temperature measured at a specific substation or measurement site, in degrees Celsius |
## Data types [#data-types]
Besides its name, every timeseries has a `data_type`, derived from its category and sub-category,
that says what kind of value it holds. It is returned in every list and accepted as a filter by the
list and search calls, so a query for "the forecasts on this entity" needs no knowledge of the
sub-category names.
| `data_type` | Holds | Example |
| ----------- | ------------------------------------------------ | ---------------------------------------------------------------- |
| `actual` | measured or realised values | `consumption.realised_load.total_load` |
| `forecast` | forecasts published by the provider | `production.forecast.wind_generation_forecast.onshore_day_ahead` |
| `price` | market and settlement prices | `price.day_ahead.day_ahead_auction_price` |
| `capacity` | installed, available and cross-border capacities | `exchange_capacity.ntc_atc.day_ahead_ntc` |
| `schedule` | plans and scheduled exchanges | `exchange.scheduled_commercial.commercial_exchange_schedule` |
| `other` | statistics and indicators | `production.indicators_shares.renewable_share_of_generation` |
# Reading values (https://grid.rebase.energy/docs/v1/guides/values/)
[`GET /entities/{entity}/timeseries/{name}/values`](https://grid.rebase.energy/docs/v1/reference/read/values/) returns the values of
one timeseries from one provider. `provider` is required, also when only one exists, so a URL never
changes meaning when a second provider arrives.
`start` and `end` are ISO 8601 instants with a UTC offset (`2026-11-09T00:00:00Z`), or bare dates
(`2026-11-09`), which mean 00:00 UTC that day. A date and time without an offset is a 400.
## Points [#points]
| Field | Meaning |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `valid_time` | the start of the interval the value is for, UTC |
| `value` | the number, or `null` where the provider published no value |
| `knowledge_time` | when the value became known: declared by the provider, or the time it was observed to appear |
| `annotation` | `null` for a value as published; otherwise a code such as `a03_forward_fill` (the provider carried the previous value forward), `a04_nowcast` or `a99_retracted` |
| `message` | only on points an upstream message stated, today the outage (REMIT unavailability) series: `{id, revision, reason, status}` of the notice behind the change-point. A cancelled or dismissed notice's point carries that notice, so `status` says why the capacity came back |
## Columns [#columns]
Most series hold one number per interval, and a point carries it in `value`. A provider that
publishes a family of numbers together, such as Elia's p10 / p50 / p90 of a forecast, holds them
as one series with several **columns**, and a point then carries a `values` object instead of
`value`, one entry per column. The metadata call lists the columns per provider in `columns`, and
the values response repeats the columns it returns in its header.
`columns` on the values call selects a subset, comma-separated; omitted, every column is
returned. Asking for a column the provider does not publish, or passing `columns` on a series with the
one column `value`, is 400.
```bash
curl "$API/entities/BE/timeseries/production.forecast.solar_generation_forecast.day_ahead/values?provider=elia&columns=p50,p90&start=2026-11-01T00:00:00Z&end=2026-11-02T00:00:00Z" \
-H "X-API-Key: $KEY"
```
```python
r = requests.get(
f"{API}/entities/BE/timeseries/production.forecast.solar_generation_forecast.day_ahead/values",
headers=HEADERS,
params={
"provider": "elia",
"columns": "p50,p90",
"start": "2026-11-01T00:00:00Z",
"end": "2026-11-02T00:00:00Z",
},
)
for p in r.json()["points"]:
print(p["valid_time"], p["values"]["p50"], p["values"]["p90"])
```
## Selecting a version with `as_of` [#selecting-a-version-with-as_of]
A value that is published again (a correction, a later estimate, a new forecast run) is kept as a
new version with its own `knowledge_time`. `as_of` selects which version is returned. The response
is **flat** (a `points` list) when `as_of` is omitted or an instant, and **snapshots** (a
`snapshots` list) when it is a period or `rolling`.
The examples read SE3 load from ENTSO-E, with `V` the values path
`$API/entities/SE-SE3/timeseries/consumption.realised_load.total_load/values`.
### Latest [#latest]
`as_of` omitted: the latest version of every value. This is the usual read.
```bash
curl "$V?provider=entsoe&start=2026-10-01T00:00:00Z&end=2026-10-08T00:00:00Z" -H "X-API-Key: $KEY"
```
```python
r = requests.get(
V,
headers=HEADERS,
params={
"provider": "entsoe",
"start": "2026-10-01T00:00:00Z",
"end": "2026-10-08T00:00:00Z",
},
)
points = r.json()["points"]
```
### As known at an instant [#as-known-at-an-instant]
`as_of` an RFC 3339 time: every value as it was known at that instant. Values published later are
absent, and values revised later come in the version known then. This shows the data as a reader saw it at
that time.
```bash
curl "$V?provider=entsoe&start=2026-10-08T00:00:00Z&end=2026-10-08T06:00:00Z&as_of=2026-10-08T01:30:00Z" \
-H "X-API-Key: $KEY"
```
```python
r = requests.get(
V,
headers=HEADERS,
params={
"provider": "entsoe",
"start": "2026-10-08T00:00:00Z",
"end": "2026-10-08T06:00:00Z",
"as_of": "2026-10-08T01:30:00Z",
},
)
points = r.json()["points"]
```
### One snapshot per period [#one-snapshot-per-period]
`as_of` an ISO 8601 duration (`PT1H`, `PT6H`, `P1D`): one snapshot per period, anchored on `start`,
or on the time of day given in `at`. Each snapshot is the whole window as known at its instant. For
example, `as_of=P1D&at=10:00` returns the window as it stood at 10:00 each day; the
[forecast versions example](https://grid.rebase.energy/docs/v1/guides/forecast-versions/) uses `PT1H`.
```bash
curl "$V?provider=entsoe&start=2026-10-01T00:00:00Z&end=2026-10-08T00:00:00Z&as_of=P1D&at=10:00" \
-H "X-API-Key: $KEY"
```
```python
r = requests.get(
V,
headers=HEADERS,
params={
"provider": "entsoe",
"start": "2026-10-01T00:00:00Z",
"end": "2026-10-08T00:00:00Z",
"as_of": "P1D",
"at": "10:00",
},
)
snapshots = r.json()["snapshots"]
```
### One snapshot per step [#one-snapshot-per-step]
`as_of=rolling`: a snapshot at every native step of the series, which is every state a live reader
could have seen.
```bash
curl "$V?provider=entsoe&start=2026-10-08T00:00:00Z&end=2026-10-08T06:00:00Z&as_of=rolling" \
-H "X-API-Key: $KEY"
```
```python
r = requests.get(
V,
headers=HEADERS,
params={
"provider": "entsoe",
"start": "2026-10-08T00:00:00Z",
"end": "2026-10-08T06:00:00Z",
"as_of": "rolling",
},
)
snapshots = r.json()["snapshots"]
```
Snapshots at which nothing was known are omitted, and snapshots stop at now even when `end` is
later. An `as_of` in the future is 400. Snapshot responses page with `next`, passed back as
`cursor`.
## Window [#window]
`start` and `end` are inclusive, UTC. A window holds at most 100,000 points at the series'
resolution; see [Limits](https://grid.rebase.energy/docs/v1/guides/limits/).
# API Reference (https://grid.rebase.energy/docs/v1/reference/)
Base URL: `https://grid.rebase.energy/api/v1`. Every request takes the API key in the
`X-API-Key` header; see [Authentication](https://grid.rebase.energy/docs/v1/guides/authentication/) for how to get a key.
The endpoints follow the three steps of every use of the API:
* **Discover**: the entity tree, one entity, the timeseries names on it, and search.
* **Describe**: the metadata of one timeseries, per provider.
* **Read**: the values of one timeseries from one provider.
The contract itself is at [`grid.rebase.energy/docs/v1/openapi.json`](https://grid.rebase.energy/docs/v1/openapi.json).
# Account (https://grid.rebase.energy/docs/v1/reference/account/me/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
# Version (https://grid.rebase.energy/docs/v1/reference/account/version/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
# Timeseries metadata (https://grid.rebase.energy/docs/v1/reference/describe/timeseries-metadata/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
# Entity tree (https://grid.rebase.energy/docs/v1/reference/discover/entity-tree/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
Every grid entity as `{id, kind, timeseries, children}`. Borders and cables are not nodes; they are relations on the entities they touch. Plants, units and portfolios are not in the tree: each grid entity's own call summarises them in `children` and pages them under `/entities/{entity}/plants`, `/units`, `/portfolios`. Order inside a level is sync areas, countries, price zones, areas, boundaries, substations, then by timeseries count.
# Entity (https://grid.rebase.energy/docs/v1/reference/discover/entity/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
# Plants in an entity (https://grid.rebase.energy/docs/v1/reference/discover/plants/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
The plants under a grid entity, descending the tree (Sweden includes SE-SE1…SE4), or a portfolio's plants. Sorted by capacity. Paged: `next` is the path of the next page, filters and `cursor` included; request it as it is. Items are plant cards, the same shape a plant has wherever it appears.
# Portfolios in an entity (https://grid.rebase.energy/docs/v1/reference/discover/portfolios/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
The portfolios under a grid entity, descending the tree: `aggregate` (an ENTSO-E unit that is several plants), `aggregator`, `virtual` (an Elexon virtual lead party) and `supplier_base` (an Elexon supplier's base demand), see `portfolio_kind`. Sorted by capacity. Paged: `next` is the path of the next page, filters and `cursor` included; request it as it is. Items are portfolio cards; the card's `plants` count says whether the portfolio's plants are linked.
# Search timeseries (https://grid.rebase.energy/docs/v1/reference/discover/search/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
# Timeseries names (https://grid.rebase.energy/docs/v1/reference/discover/timeseries-names/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
# Units in an entity (https://grid.rebase.energy/docs/v1/reference/discover/units/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
The generation units (machines) under a grid entity, descending the tree; a plant's units; or, on a portfolio, the units of every plant that names it: every battery in DE-LU in one call, rather than one call per plant. Sorted by capacity. Paged: `next` is the path of the next page, filters and `cursor` included; request it as it is. Items are unit cards.
# Values of many timeseries (https://grid.rebase.energy/docs/v1/reference/read/many-values/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
The latest values of up to 2,000 timeseries over one shared window, in one call. The body
lists the series; the response holds one block per series, in the same order, each exactly
what the one-series values call returns for it. A series that cannot be read (unknown
entity, name or provider, a window too large for it) answers an `error` block instead, and
the rest are still read.
A page holds whole series, up to 200,000 points in total and at least one series. When
the next series would go over, the page stops and `next` is set: send it back as `cursor`
with the same body. One call counts as one request against the rate limit.
# Timeseries values (https://grid.rebase.energy/docs/v1/reference/read/values/)
{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}
One point per interval of the series, each with its `valid_time`, `value`, `knowledge_time`
and `annotation`; a point an upstream message stated (an outage change-point) also carries
that `message` (id, revision, reason, status). `as_of` selects the version:
| `as_of` | Response | Returns |
| ------------------------------------ | ----------- | ------------------------------------------------------- |
| omitted | `points` | the latest version of every value |
| an RFC 3339 instant | `points` | every value as known at that instant |
| an ISO 8601 duration (`PT1H`, `P1D`) | `snapshots` | one snapshot per period, anchored on `start` or on `at` |
| `rolling` | `snapshots` | one snapshot per native step of the series |
A snapshot is the whole window as known at its instant. Snapshots at which nothing was known
are omitted and they stop at now even when `end` is later; an `as_of` in the future is 400.
Snapshot responses page with `next`, passed back as `cursor`. The Reading values guide shows each
case with an example.