Magidoc

Dangerous changes

Learn about recent and upcoming dangerous changes to the EAC GraphQL API.

About dangerous changes

#

Dangerous changes are modifications that maintain API compatibility but may impact how your application behaves at runtime. These changes typically include adding new enum values, introducing new validation rules, or modifying business logic that could affect auction outcomes or data processing.

While your existing queries will continue to work, these changes may require updates to your application logic to handle new scenarios or comply with updated validation requirements.

Dangerous changes log

#

Dangerous changes for deployment in production on 2025-06-25

#

In this release, a new overbidding prevention validation rule has been added for baskets associated with battery units providing Response services. This validation ensures that battery units maintain sufficient capacity in the opposite direction of their bids, enabling them to realistically deliver on their commitments. The rule applies specifically to bidirectional baskets and requires a specific percentage of the requested volume to be reserved in the opposite direction, varying by service type. Market participants operating battery units are advised to ensure their bid volumes consider the required capacity reservations in opposite directions when submitting baskets for Response services.

Dangerous changes for deployment in production on 2024-10-01

#

In this release, a new validation rule has been added on the basket family IDs. When submitting baskets to an auction, the same family ID cannot be used across multiple units in a single auction submission. This validation ensures that family constraints are correctly applied on a per-unit basis in the auction algorithm. This validation rule, aligned with the intended market design, enforces a constraint that was always present in the algorithm but not previously checked in the input. It is important to note that this change does not affect auction outcomes, as the algorithm has always applied family constraints on a per-unit basis. Market participants that are using the family IDs for their baskets are invited to check that the IDs forwarded to EAC do not have the same value for different units in a given auction.