7.1.0

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

For the planned release timeline and a full list of changes (including GUI features) please refer to the 📄 Release Notes article in the ❓Help / FAQ of Empire.

🚨 Breaking Changes

Webhooks

The value set of the reasonCode field of the webhook events related to Unplanned Outages has been changed. The new value set is

• FAILURE
• FORESEEN_MAINTENANCE

7.0.0

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

For the planned release timeline and a full list of changes (including GUI features) please refer to the 📄 Release Notes article in the ❓Help / FAQ of Empire.

🚨 Breaking Changes

Finance Invoices

We’ve updated the Finance API with improved clarity and flexibility around invoice handling:

• The getFinanceInvoices endpoint (GET /v1/finance/invoices) has been renamed to getFinanceInvoiceGroups (GET /v1/finance/invoice-groups) for better alignment with the returned data
• In the InvoiceGroup object, the fields netAmount, grossAmount, and lastStatusChange are now optional
• A new required field, type, has been added to the InvoiceDetails object (used in getFinanceInvoice)

Bid Document & Allocation Results XML

As per a participant's request, the Bid document XML and the Allocation results XML documents can be mapped together: Bid Document XML, BidTimeSeries.BidIdentification is mapped to Allocation Results XML, AllocationTimeSeries.BidIdentification.
Bid Document XML:

   ...
   <BidTimeSeries>
     <BidIdentification v="example bid tag1" />
     <AuctionIdentification v="BDL-GB-NL-P-BASE---250725-01" />
     ...

Allocation Results XML:

  ...
  <AllocationTimeSeries>
    <TimeSeriesIdentification v="f1VyA6FGRkmHsPqM4gb8Tg"/>
    <BidDocumentIdentification v="BDL-GB-NL-P-BASE---250725-01"/>
    <BidDocumentVersion v="1"/>
    <BidIdentification v="example bid tag1"/>
    <AuctionIdentification v="BDL-GB-NL-P-BASE---250725-01"/>
    ...

Also, the Allocation results XML document AllocationTimeSeries.Period.Interval.BidPriceAmount has been modified. Before the changes, it contained the weighted average price of the allocated capacity.
For example, the participant had 3 bids: 17 MW, 27€; 15 MW, 25€; 12 MW, 22€. Before Empire 7.0 the weighted average for these would be ~24.95
After this release, the intervals and the amounts are listed per bids, not the weighted average is calculated in order to have an accurate value.

Feature Changes

Finance / Invoice sending

The Netting statement pdf header is going to be the generation period. Before the release, the header of the netting statement showed the Invoicing Period. Since the invoice covers more than just the previous month, we changed this to the month the invoice was generated in the system, in order to avoid confusion. For example, the Invoice generated on the 1st of November 2025, the header is November-25, instead of October-25.
A slight modification has been made to the exchange rate notation: whole numbers will now be explicitly written out. For instance, "0.54200" will be used instead of ".54200".

Finance / Credit Limit Calculation
We've fixed an edge case in the Credit limit calculation - Returns logic. The logic did not consider the return compensations of monthly auctions, with delivery periods more than one month ahead. This was due to a restriction in the credit limit check. The updated logic now includes all future delivery months, ensuring accurate Credit Limit calculations.

Email & Messages
We've fixed an issue where the “Show in Empire” button in participant emails linked to a page that the recipients couldn't access. It now correctly redirects to the right page for a better user experience.

We've fixed an issue where messages for expiring and expired API keys were swapped. Users were receiving misleading notifications. The correct messages are now sent based on the API key's actual status.

Reporting

We’ve fixed issues in the Bought and Sold Capacity report related to Long Term auction calculations and missing Day-Ahead (DA) buy data. The report now properly includes DA auctions in the Buy section and aligns all calculations with the expected logic.

Audit log report now contains the user name in the email column. Now, the email addresses are listed.

We’ve corrected a billing report issue in Empire, where Quarterly and Annual products displayed the incorrect number of allocated hours during planned outages. The report now correctly reflects the invoiced hours, aligning with the Monthly product calculation.

⬇️Minor fixes

We’ve fixed an issue where invited users could become suspended before completing activation, due to repeated failed login attempts. Invited users now remain in a pending state until activation, preventing unintended suspension.

In the Empire GUI, where the tables are too long, the headers are "Fixed" to ease readability.

The createSecondaryMarketReturnRequest should return a 201 code if the creation was successful. Previously, it returned 200.

We’ve fixed an issue where the system incorrectly accepted default bid requests for the createDayAheadOrIntraDayDefaultBid endpoint, with all MTUs bundled in a single object. The system now correctly validates the MTU structure and rejects improperly formatted requests.

6.1.x

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

❗Please note that these release notes general for the 6.1.x functionality. Always ensure that you are always integrating to the latest patch version of the specification.

For the planned release timeline and a full list of changes (including GUI features) please refer to the 📄 Release Notes article in the ❓Help / FAQ of Empire.

---

Version 6.1.0 is an internal feature release providing the ability to integration with GOPACS, no impact on Participant integrations and functionalities.

6.0.x

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

❗Please note that these release notes general for the 6.0.x functionality. Always ensure that you are always integrating to the latest patch version of the specification.

For the planned release timeline and a full list of changes (including GUI features) please refer to the 📄 Release Notes article in the ❓Help / FAQ of Empire.

🚨 Breaking Changes

Buy Now Offers 2.0

With the new release, this function has been redesigned to improve purchasing capacity usability, provide a more transparent interface, and make it easier to browse purchased capacities.

New endpoint

• getBuyNowOfferPurchaseDetails - GET /v1/buy-now-offers/purchase
  • Participant organisations can retrieve the purchased capacities and their prices for an MTU in the given direction and timescale

Removed endpoint

• getBuyNowOffer - GET /v1/buy-now-offers/{id}
  • With the new setup, the offer pools are listed per MTU for the given delivery day, direction and timescale. The OC pools are retrieved with the getBuyNowOffers, while the exact purchases are fetched with the purchaseBuyNowOffer endpoint.

Modified endpoints

• getBuyNowOffers - GET /v1/buy-now-offers
  • This endpoint lists the offered Buy Now capacities per MTU for the given delivery day, direction and timescale
  • parameters:
    • X-Participant-Id is introduced and required for Participants, where their own Participant ID must be added
    • The sortBy and productType parameters are no longer needed, as the whole day will be retrieved with the new setup
  • response:
    • The validityPeriod, status, oc, currentPrice, nextPrice fields are sent per MTU from now on.
    • There are new/renamed fields: allocatedAc (total allocated capacity for the MTU) and totalPrice (for the sum of the capacity x price for the MTU).
    • The direction is no longer retrieved, and the purchasedBy is moved to the getBuyNowOfferPurchaseDetails endpoint
    • The values of participantCount and expiredOc fields will always be NULL for participants.
• purchaseBuyNowOffer - PUT /v1/buy-now-offers/purchase
  • The purchase is not per buy now offer, but per MTU(s) for the given delivery day, direction and timescale. The purchase is a “form”, where the requested capacities are submitted for each MTU/MTUs.
  • request:
    • Instead of sending the offerId, the deliveryDay, borderDirection and timescale fields are used to identify the purchase
    • The MTU’s mtuStart and requestedCapacity array is used for requesting the capacity

Bidding Configuration

Bidding Configuration can now independently be specified for each timescale (Long Term, Day Ahead, Intraday) separately, this means a breaking change in the payloads of the getBiddingConfiguration and setBiddingConfiguration endpoints.

From this version Bids sent with the submitLongTermBids or submitDayAheadOrIntraDayBids operations are to be validated against the respective timescale's bidding configuration independently.

Profile Details Changes

When fetching and setting the currently logged in User's profile using the getProfileDetails and updateProfileDetails operations, new fields has been added to handle Timescale Preferences and Notification Preferences.

Both features are affecting the GUI, has no effect on the operation of the Platform API.

Python SDK dependency upgrades

The generated Python SDK published as empire-platform-api-public-client now uses updated dependencies for Pydantic (>=2) and urllib3 (>= 1.25.3, < 3.0.0)

Disabled API Key Management

Due to security reasons API Key management endpoints (getApiKeys, createApiKey, deleteApiKey operations) are no longer accessible using API Keys, only through the GUI.

New Features

Webhooks

With version 6.0 webhooks has been introduced to reduce the need of constant polling for changes in the system. Webhooks are triggered in an event-driven way sending real-time updates to Participant systems.

Due to security reasons Webhook management endpoints are not available through the Platform API, only Empire's GUI.

A detailed guide has been published on the Wiki about Webhooks. Please pay close attention the Webhook Security section for securing the communication.

Auction Overview

With this release a new operation is introduced to where the most relevant Auctions are listed: bidding for currently open Auctions, Auctions where the Participant has just won capacity, and cancelled Auctions. The new operation is called getAuctionOverview with details available in the documentation.

Final Auctions showing up in the Auction Schedule

Auctions that got into FINAL_RESULTS_PUBLISHED state previously were only accessible from the Auction Results list accessed by the getAllocatedAuctions operation.

Starting from this version, these Auctions will also show up in the Auction Schedule list accessed by the getAuctions operation.

5.0.x

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

For the planned release timeline and a full list of changes (including GUI features) please refer to the 📄 Release Notes article in the ❓Help / FAQ of Empire.

🚨 Breaking Changes

Finance / Invoicing structure

Invoice line items are sorted into different invoice types: Standard invoice (SI), Sales Credit (SC), Self-Billing invoice (SB), and Netting Statement document (NS). The latter aggregates the values of each previous invoice documents.

The getFinanceInvoices endpoint now retrieves all the invoice document types resulting in changes in the response structure, e.g the concept of Invoice Groups has been introduced. Please study the response carefully to prepare for the changes.

Finance / Extended Overview information

The getParticipantDashboardFinanceOverview and getParticipantOverview endpoints are extended with the values of the unpaid invoices (including SI, SB, SC, and total values), and the Credit Utilization (including un-invoiced liability, un-invoiced compensation, pending bids price and credit utilization) resulting in changes in the response structure.

Finance / Settlement parameter changes

When querying the getFinanceSettlementPerDay or getFinanceSettlementPerSource endpoints the productTypes query parameter became optional which itself won't cause a breaking change.

On the other hand the optional timescale query parameter name has been changed to timescales (plural) to allow filtering for a list of Timescales (Long Term, Day Ahead, Intraday) instead of one, which is a potential breaking change.

Secondary Market / Participant ID parameter change in Return Requests

When querying Return Requests on the Secondary Market using the getSecondaryMarketReturnRequests operation, the X-Participant-Id parameter name has changed to X-Participant-Ids (plural) but Participants are still required to submit their own single Participant ID.

New Features

Auctions / Previous and next Auction ID

For usability purposes, to step between Intraday and Day Ahead auctions, the getDayAheadAuction, getPublicDayAheadAuction, getIntraDayAuction, getPublicIntraDayAuction endpoints retrieve the IDs of the previous and next Auctions on the same timescale in the previousAuctionId and nextAuctionId properties.

Besides the extra properties, the response structure has not been changed.

Auctions / Extended Allocated Auction filters with Bidding Period

The following endpoints have new filter parameters added for the Bidding Period: getAllocatedAuctions, getPublicAllocatedAuctions, getAggregatedAllocatedAuctions, and getPublicAggregatedAllocatedAuctions.

You can use the optional biddingPeriodStart and biddingPeriodEnd query parameters for filtering.

Finance / Download PDFs for an Invoice Group

Along with the change in the invoicing structure it became possible to download all documents (SI, SC, SB, NS) in a ZIP archive that belong to a specific Invoice Group using the new downloadAllFinanceInvoiceGroupPdfs endpoint which only requires the ID of the Invoice Group which can be queried using the getFinanceInvoices operation.

Buy-Now Offers / Fetch a single Buy-Now Offer

A new endpoint called getBuyNowOffer has been added to query the information for a single Buy-Now Offer by its ID.

New Reports

The following reports became available for the Participants:

Name	Operation ID	Description
Auction Bids Report	getAuctionsBidsReport	Lists all Bids for a Participant for a given timeframe in an Excel file
Download Invoice Documents	getFinanceInvoicePdfs	Generates a ZIP file, including the invoice files generated within the selected period: Standard invoice (SI), Sales Credit (SC), Self-Billing invoice (SB), and Netting Statement document (NS)

4.0.x

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

For the planned release timeline and a full list of changes (including GUI features) please refer to the 📄 Release Notes article in the ❓Help / FAQ.

🚨 Breaking Changes

External ID renamed to Bid Tag

The externalId field which has been introduced in v1.1.0 is renamed to bidTag in the getLongTermAuctionBids, submitLongTermAuctionBids getDayAheadOrIntraDayAuctionBids and submitDayAheadOrIntraDayAuctionBids endpoints.

The purpose of the field remains the same: it allows Participants to tag their bids with an arbitrary identifier of their choice. This can be used for example to identify bids made by different traders. The previous values that has been submitted under the externalId field will be returned in the bidTag field.

New Features

New Finance Reports available

The following new Reports are available for the Participants to download as XLS files:

Name	Operation ID	Description
Bought or Sold Capacity Report	getFinanceBoughtOrSoldCapacityReport	Report detailing a Participant's own bought and sold capacity
Auction Results Settlement Report	getFinanceAuctionResultsSettlementPerParticipantReport	Report detailing a Participant's own Auction Results Settlements

3.0.x

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

For the planned release timeline and a full list of changes (including GUI features) please refer to the 📄 Release Notes article in the ❓Help / FAQ.

🚨 Breaking Changes

Filtering for multiple enum values in Auction Schedule and Auction Results

As per multiple Participant requests the query parameters for retrieving the Auction Schedule and Auction Results has been uniformised to support multiple values for both internal and public endpoints.

Multiple values are always joined with an OR logical operator and can be specified by repeating the query parameter the desired times. For example you can send the GET /v1/auctions?timescales=LONG_TERM&timescales=DAY_AHEAD request to get a list of scheduled Long Term OR Day Ahead Auctions.

The following parameters has been renamed:

OperationId	Path	Old Parameter ❌	New Parameter ✅
getAuctions	GET /v1/auctions	timescale productType status	timescales productTypes statuses
getAllocatedAuctions	GET /v1/allocated-auctions	timescale	timescales
getAggregatedAllocatedAuctions	GET /v1/allocated-auctions/aggregated	timescale	timescales
getPublicAuctions	GET /v1/public/auctions	timescale productType status	timescales productTypes statuses
getPublicAllocatedAuctions	GET /v1/public/allocated-auctions	timescale	timescales
getPublicAggregatedAllocatedAuctions	GET /v1/public/allocated-auctions/aggregated	timescale	timescales

Query Allocation Results Report by "Display ID"

The getAuctionAllocationResultsReport (which fetches allocation results in "ECAN Allocation Results Document v4.0" format) now supports querying by both an "Internal ID" or a "Display ID".

• Internal ID
  • in UUIDv4 format, can be obtained from the browser URLs or the id field of an Auction object
  • example: 76a8072b-3fdd-459c-8f4a-3b443424d7ac
• Display ID
  • shown on the GUI, or can be obtained from the displayId field of an Auction object
  • example: BDL-NL-GB-M-BASE---240401-01

This change is only breaking integrations, if you are using the 🐍 Python Client SDK or otherwise utilise code generation based on the published 📚 openapi.yaml file, as only the internal parameter name has been changed from id to idOrDisplayId, the request path uses the same schema as GET /v1/reporting/auctions/<ID>/allocation-results.

2.0.0

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

For the planned release timeline and a full list of changes (including GUI features) please refer to the 📄 Release Notes article in the ❓Help / FAQ.

🚨 Breaking Changes

Removed allocated capacities for Day Ahead and Intraday Auction timescales

For Participants the allocated Transmission Rights in Day Ahead and Intraday Auctions are no longer available to query for other Participants, only for themselves. This means that the getDayAheadOrIntraDayAuctionParticipantResults operation can be only executed with someone's own Participant ID.

Removed access for Finance / Auction Results Settlement Report

Participant access for the getFinanceAuctionResultsSettlementReport operation has been removed in this version, as per BritNed’s revised requirements.

XML tag names in Auction Allocation Results Report

The formatting of tag names has been changed in the resulting XML file of the getAuctionAllocationResultsReport operation to fully comply with the format JAO has been using to generate these files. Important to note that no semantical changes has been introduced to the files.

The tag names in the XML file are now uniformly formatted as "upper camel case / Pascal case" resulting in changes like subjectRole => SubjectRole or businessType => BusinessType. If you relied on case-sensitive parsing of XML tags, changes in integration code might be necessary!

New Features

Allow 0 Bid Price for LT bids

In order to be fully compliant with BritNed's Access Rules setting a Bid Price to 0 has been made available (with a >0 Bid Capacity) for Long Term Auctions. For the full list of Bidding Validation rules please refer to the relevant Wiki article.

New Finance Reports available

The following new Reports are available for the Participants to download as XLS files:

Name	Operation ID	Description
Credit Cover Report	getFinanceCreditCoverReport	Report detailing a Participant's own Credit Cover has been made available
Credit Limit Report	getFinanceCreditLimitReport	Report detailing a Participant's own Credit Limit has been made available
UIoSI Hourly Report	getFinanceUiosiHourlyReport	Besides the already available daily aggregation of the UIoSI Report (with ID getFinanceUiosiReport) a new one has been added with an hourly resolution

1.1.0

Below you can find explanations of breaking and otherwise notable changes in this release. For a complete list of changes please refer to 📖 CHANGELOG.md and 📚 openapi.yaml in the repository.

Notable Changes

External ID for Bids

A new string field called externalId is introduced for the submitLongTermAuctionBids and submitDayAheadOrIntraDayAuctionBids endpoints which allows Participants to tag their bids with an arbitrary external identifier of their choice. This can be used for example to identify bids made by different traders.

The value of externalId is returned on the getLongTermAuctionBids and getDayAheadOrIntraDayBids endpoints, and will be displayed on the Web Frontend in a tooltip (although only editable through the Platform API).

Additional Filters for Auction Results List

In API version 1.1.0 authenticated counterparts of the Public / Allocated Auctions endpoints are introduced under the Allocated Auctions tag serving an authenticated version of the Auction Results List.

This allowed us to add filters for cleared Auctions that a Participant has either placed bids on, or even received some capacity from.

The authenticated endpoints has two optional parameters introduced called X-Participant-Id and participantStatus which can be used with the following logic:

• either both or none of them need to be specified
• Participants must submit their own Participant ID in the request
• control the filtering with the PLACED_BIDS or RECEIVED_CAPACITY values in the participantStatus parameter

Resend / Revoke User Invites

In order to ease the onboarding process, once a User has been confirmed and initially invited by BritNed and Empire Helpdesk, Participants can control resending and revoking invitations for these Users.

This means that the resendUserInvite and revokeUserInvite endpoints are now accessible with the MANAGE_OWN_USERS and MANAGE_ANY_USERS Permissions, in practice attached to the "Participant Admin" role.

This change will be reflected on the Web Frontend as well, enabling the "Resend" and "Revoke" buttons when the necessary Permissions are present.

Pre-Nomination Options

A new endpoint called getAggregatedPreNominationOptions has been added which allows the querying if pre-nominations already exist for the given X-Participant-Id for the specified deliveryDay - Participants must submit their own Participant ID.

Auction List Status Filtering

The optional status filter parameter in the getAuctions and getPublicAuctions endpoints has been previously specified with the full set of valid Auction Statuses.

As the Auction Schedule List (which is served by the above mentioned endpoints) by definition does not contain Auctions in the FINAL_RESULTS_PUBLISHED status, this value is now removed from the valid filter options to further clarification.

Fixing Python SDK date/time handling

Issues #4 and #5 has been raised about the incorrect date/time handling in the Python Client SDK which are mitigated with this release.