Use with an agent

An agent needs one thing: one of the files below. No API key is required (Use without a key): 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).

What to give the agent

Three machine-readable entry points are published with these docs:

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

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

• 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.
• 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.
• Read several timeseries in one request. POST /timeseries/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.
• 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

• 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: the whole tree;
  2. GET /entities/{entity}: one entity with its parent, children and relations;
  3. GET /entities/{entity}/timeseries: the names on it, with their providers.
• Then search. Once the entities and the naming are known, GET /timeseries 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}. 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

• 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

• 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

• One many-series call instead of N values calls. When a job needs the same window from several timeseries, POST /timeseries/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. Metadata is also one call per timeseries.

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).