entsoemcp.com

ENTSO-E European power-market data: prices, load, generation, cross-border flows, outages. Hot-path is DuckDB-over-Parquet — queries are sub-second over the cached ingest. Use `data_coverage` before assuming a recent date is landed. DATE CONVENTION (read before every series query): • Default: `start`/`end` are UTC. `start` is INCLUSIVE, `end` is EXCLUSIVE — i.e. ts_utc ∈ [start, end). • For 'all of April 2026' use start=2026-04-01, end=2026-05-01 (NOT end=2026-04-30 — that drops April 30 entirely, plus any local-time hours of April that fall on UTC dates outside the window for non-UTC zones). • For 'yesterday' use start=YESTERDAY, end=TODAY. MARKET-DAY CONVENTION (use this for any 'what was the price on day X' question): • The SDAC pan-European day-ahead auction defines its delivery day on a CET/CEST-aligned 24-hour grid for every coupled bidding zone — same UTC window for DE_LU, ES, GR, FI, PT, etc. (EPEX SPOT MRC process: 'All timings indicated in this document are CET timings'). UTC midnights slice off the last 1–2 hours of the real market day and pull in 1–2 from the next. • For market-day questions ('yesterday's DE_LU baseload', 'May 2026 ES capture rate'), pass tz='Europe/Berlin' so the window aligns to the auction's delivery day. Example: get_day_ahead_prices(zone='DE_LU', start='2026-05-11', end='2026-05-12', tz='Europe/Berlin') returns exactly the 24 SDAC delivery hours for May 11. • For per-zone-local-clock questions (rare; consumer-style: 'when was the consumption peak in Spain yesterday in Madrid time?') pass tz='local' — resolves to the zone's own IANA tz (Europe/Madrid for ES, etc.), NOT the auction grid. • For zone-agnostic / cross-time-zone analysis, keep the UTC default. • Responses always include a `period` field with start_utc, end_utc, duration_hours, and (when a zone is involved) start_local/end_local — verify duration_hours matches your intent (a 30-day month is 720 h). • aggregation='daily'|'monthly' buckets follow the resolved tz: UTC by default; with tz= set, buckets align to that tz's day/month and are labeled by the local period start as a plain 'YYYY-MM-DD' string (the period block echoes bucket_tz). Market-day daily means = tz='Europe/Berlin' + aggregation='daily' in one call. DATA RESOLUTION (read before per-hour math): • Most endpoints publish at PT60M (one row per hour). Some zones have rolled over to MTU=15min (PT15M) for select endpoints — notably `day_ahead_price` for DE_LU, and `actual_load`/`generation_per_type` across many zones. Data is stored at the native resolution it was published at. • For day-ahead prices specifically: the auction still clears HOURLY, so the 4 quarter rows of an hour all carry the same price value. An hourly AVG of PT15M DA prices equals the original hourly price; a SUM would 4× over-count. • For per-hour math on raw rows: aggregate to hourly first via `DATE_TRUNC('hour', ts_utc)` + AVG, THEN operate. The `get_derivation` tools handle this internally — `capture_price`, `negative_price_hours`, `residual_load`, `res_share`, `tb_spread` all aggregate to hourly before counting/averaging so the per-hour math is consistent across zones. • For raw-row consumers: check the response row count vs expected hours. 2880 rows for a 720-hour April → PT15M storage; 720 rows → PT60M. Use `aggregation='hourly'` on `get_series` (or the `/api/series` / `/download` query param) to collapse to one row per hour at query time, regardless of native storage.