Skip to main content

22 September 2026 - Interconnection Data Update: Consistent Border Naming, JAO Virtual Bidding Zones

Written by Maxwell Kahn

We will be making a series of changes across our interconnection endpoints, live from Thursday, 24 September. No fields have been removed from any response; existing fields keep their name and meaning throughout. In short, there are three changes across this release:

  1. New parameters & response fields: new query parameters and response fields make it easier to identify exactly what a row represents.

  2. One name per border: until now, the same physical border could appear under several different names depending on the provider, or under a name you could not query for. Each border is now published under a single, stable name.

  3. Virtual bidding zones: JAO's virtual bidding zones are now directly queryable, alongside physical bidding zones.

Here is how each applies per impacted endpoint.


Net Transfer Capacities

Endpoint: /power/interconnections/net-transfer-capacities

  • New parameters & response fields

    • Parameters: borderLevel (zone, interconnector, or all - default all, today's behaviour) and counterpartyZone, to keep only the borders between a zone and one counterparty.

    • Response fields: fromZone/toZone, the border key.

  • One name per border

    • zone=FR previously returned the France-Italy border three times (FR>IT, FR>IT-NORTH, FR>ITCP); it is now returned once, as FR>IT-NORTH. If you're currently filtering the response on "IT", or query using a retired identifier like ITCP, you will lose that series - you can use counterpartyZone=IT-NORTH instead to get the relevant border.

    • zone=DE-LU now returns 16 borders instead of 6: several DC links, and the BE to DE-LU border, were not previously reachable.

  • Virtual bidding zones

    • from/to can now show a virtual bidding zone name where you previously saw a zone name - for example, the DE-LU to DK1 border now appears as DE-DK1-VH to DK1-DE, with DE-LU/DK1 carried separately in fromZone/toZone. Grouping on fromZone/toZone keeps this series stable regardless.

API response before/after

params="zone": "DE-LU", "horizon": "DayAhead"
// before
{"startDate": "2026-09-01T00:00:00+00:00",
 "from": "DE-LU", "to": "DK1", "value": 3500.0, "provider": "entsoe"}

// after
{"startDate": "2026-09-01T00:00:00+00:00",
 "from": "DE-DK1-VH", "to": "DK1-DE", "fromZone": "DE-LU", "toZone": "DK1",
 "value": 3500.0, "provider": "nordpool"}


Net Positions & Max Net Positions

Endpoints: /power/interconnections/net-positions & /power/interconnections/max-net-positions

  • New parameters & response fields

    • Parameter: region (core or Nordic), returns a full domain's bidding zones and virtual bidding zones together.

    • Response fields: ownerZone, counterpartyZone and region - always present, null where they do not apply, so the row shape is unchanged. Values on existing series are unchanged.

  • Virtual bidding zones

    • The zones parameter now accepts 30 new values - JAO's virtual bidding zones (ALDE, DE-DK1-VH, NO2-NK, and others) - and becomes optional if region is provided.

API response before/after

params="zones": "FR", "provider": "jao"

// before
{"startDate": "2026-09-01T00:00:00+00:00",
 "zone": "FR", "value": -1676.38, "provider": "jao"}

// after: same value, three new fields
{"startDate": "2026-09-01T00:00:00+00:00",
 "zone": "FR", "ownerZone": null, "counterpartyZone": null, "region": "core",
 "value": -1676.38, "provider": "jao"}

// after: a virtual bidding zone, which before was rejected as an unknown zone
// params: {"zones": "DE-DK1-VH", "provider": "jao"}
{"startDate": "2026-09-01T00:00:00+00:00",
 "zone": "DE-DK1-VH", "ownerZone": "DE-LU", "counterpartyZone": "DK1", "region": "core",
 "value": -1261.12, "provider": "jao"}


Commercial Scheduled Exchanges

Endpoint: /power/interconnections/commercial-schedules

  • New parameters & response fields

    • counterpartyZone parameter.

    • borderLevel parameter - it controls whether the response includes zone-level exchanges, interconnector-level exchanges (where available), or both. Optional, defaults to all - today's behaviour, so no existing series are affected. Example:

      • borderLevel=all - returns FR-GB exchanges plus FR-IFA, FR-IFA2 and FR-ELECLINK individually. Summing all of these will double-count the GB-FR border.

      • borderLevel=zone - returns only the FR-GB zone-level exchanges. Safe to aggregate.

      • borderLevel=interconnector - excludes the FR-GB zone-level pair and returns the three individual interconnectors breakdowns instead. Safe to aggregate.

API response before/after

params="zones": "FR", "marketType": "DayAhead","borderLevel": "zone", "provider": "rte"
// before: 240 rows. No FR to GB series at all.
{"startDate": "2026-09-01T00:00:00+00:00",
 "from": "BE", "to": "FR", "value": 0.0, "provider": "rte"}

// after: 288 rows. FR to GB appears, as the sum of the three cables.
{"startDate": "2026-09-01T00:00:00+00:00",
 "from": "FR", "to": "GB", "value": 2061.0, "provider": "rte"}


Full API documentation will be updated once the changes are released. If you have any questions, please reach out to cs@kpler.com.

Did this answer your question?