Standalone baskets

This page documents standalone basket submission through enterBaskets .

The basket composite APIs are the recommended long-term direction because they support:

• looped families through explicit loopFamilies
• flexible groups and minimum consecutive service windows rules
• linked service windows
• future products and basket submission features

Use this standalone flow only if you intentionally need the legacy enterBaskets mutation. If your baskets must be grouped explicitly, or if you are starting a new integration, use Basket composites instead.

First you need to retrieve the Auction Session for which you want to create a basket. Use the auctionSessions query to retrieve the list of all auction sessions you have access to. In particular, we are interested in retrieving the ids of the service windows that we will use for creating baskets. Note that the service windows have unique ids, changing every day.

Refer to the Retrieve auction sessions section for an example.

You will also need to retrieve the list of your Units registered into the SMP (Single Market Platform). Use for example the following query.

With the Auction Session retrieved previously, you have access to the list of Service Windows of the auction. Each service window belongs to a specific Service Type . To create a Basket , you will also need the list of Services belonging to each service type. To retrieve all Services, you can use the following query.

For readability, only 2 services are returned in this example, more will be available in practice.

Use the enterBaskets mutation to create one or multiple standalone baskets at once. If the validation of one of the basket fails, none of them will be created. For each basket, some information will be required, let us go through it step by step.

If your baskets must be looped together through explicit grouping, or must be submitted as a flexible group, use enterBasketsComposite instead.

First, you need to define a name for your Basket and select a Unit and a Service Window.

Note that a Service Window is linked to a given Service Type and a given Auction Session. All orders of a Basket must exclusively use Services with the same Service Type and that are available for the selected Unit.

Then you need to provide a parent order. Give it a price and positive volumes for the services of the Basket’s service type for which you want to bid. The list of volumes may be empty, but you can have at most one item per service.

Optionally, you can also provide some child orders. As for the parent order, give them a price and positive volumes for the services of the Basket’s service type for which you want to bid. Each child order must have at least one non-zero volume and at most one item per service. Up to 10 substitutable and up to 10 non-substitutable child orders are allowed.

All together it gives us the following query

The EAC is performing some validations to ensure the baskets respect the market rules.

Most of the validation rules are directly explained field by field in the GraphQL reference, see BasketInput for the specifics on baskets creation.

If NESO links service windows for a given service, enterBaskets cannot be used. Refer to Impact on baskets submission for more information.

The validation rule on the unit capacity is a bit more complex and deserve to be explained in more details.

When creating or updating a basket, the EAC checks if accepting the basket at its maximum volume would exceed the unit capacity and rejects the baskets when it's the case. Due to the multi-services setup and the fact that unit capacity is not a simple linear function when split between multiple service, this validation is a best effort rule to prevent encoding errors. Market participants remain responsible to ensure their baskets are compliant with what their units can deliver.

The capacity check is done at multiple levels. It is performed for each service individually, but also considering all low services together and all high services together. So for a basket with DCL, DCH and DML, there is 5 different capacity validations, one per service plus one for high and one for low services.

First the EAC computes the basket maximum volume. It first computes the maximum volume of each order (parent, child and substitutable child orders) by summing the volumes of all concerned services. The basket maximum volume is then computed as the sum of:

• the maximum volume of the parent order
• the maximum volumes of all the child orders
• the maximum volume of the substitutable child order having the higher maximum volume

Then the EAC computes the unit capacity. A unit is prequalified for a given capacity for each service. This capacity may change slightly between services. As a basket covers multiple services, a single capacity must be computed. As a best effort the maximum capacity allocated to concerned services is used. Note that services for which there is no orders in the basket are ignored.

If the basket maximum volume exceeds the unit capacity, the basket is rejected.

For example, if we have a basket with:

If the unit has a capacity of 25 MW for DCL, 20 MW for DML, 20 for DCH and 26 for DRL, the basket is valid because

• DCL only: 10 + 3 + 0 + max(5, 2) = 18 <= 25
• DCH only: 11 + 0 + 4 + max(0, 0) = 15 <= 20
• DML only: 2 + 2 + 0 + max(1, 3) = 7 <= 20
• high services: (11) + (0) + (4) + max((0), (0)) = 15 <= 20
• low services: (10 + 2) + (3 + 2) + (0) + max((5 + 1), (2 + 3)) = 23 <= 25 = max(25, 20)

An overbidding prevention rule is applied to baskets associated with battery units providing Response services. This rule ensures that units maintain enough capacity in the opposite direction of their bid to realistically deliver on their commitments.

Specifically, for bidirectional baskets, each service (DC, DM, DR) requires a certain percentage of the requested volume to be reserved in the opposite direction. The values of those percentages vary depending on the service. The following table provides the current percentages, for the most up-to-date values, please to the EAC webpage .

Applicability: This rule only applies to:

• Battery units
• Bidirectional baskets (having non-zero volumes for services in both up and down directions)
• Response services

Validation Process:

1. Calculate required capacity per order: For each order (parent, children, substitutable children):
   • Sum volumes of all services in each direction
   • Add reserved capacity: volumes in opposite direction × service percentage
2. Handle substitutable children: Take the maximum required capacity per direction across all substitutable children
3. Calculate total required capacity: Sum the required capacities from parent order, all child orders, and maximum substitutable child capacity
4. Capacity check: Compare total required capacities against unit's generation and demand capacities

Example: A unit bidding 15 MW DRH, 25 MW DCH, and 40 MW DML requires:

• High direction: 15 + 25 + (40×0.2) = 48 MW demand capacity
• Low direction: 40 + (15×0.4 + 25×0.1) = 48.5 MW generation capacity

If a unit lacks demand or generation capacity data when this rule applies, the validation automatically fails. Refer to SMP to review your unit's capacities.

Retrieving your baskets is straightforward. Use the baskets query to list all your baskets for a given auction using the auction session identifier.

When you create a basket, the EAC GraphQL API will assign a unique id to each basket. This id can be returned by the enterBaskets mutation as shown in the basket creation section.

To update a basket, simply use the enterBaskets mutation. It works the same way as for creating new baskets except that you provide the id of the basket to update. Note that a new unique id will be assigned to the updated basket, the update works as a delete then create operation.

To update the name of your basket as well as adding or removing child orders, you simply resubmit the complete updated basket using the same id.

If you want to get rid of one of your baskets, use the removeBasket mutation. Simply provide the unique identifier of the basket you wish to delete.

To delete all baskets for an auction session, use the removeBaskets mutation. Specify the identifier of the auction session in the mutation and all baskets for that auction will be deleted. Optionally, you can also specify a unit, a service window, or basketIdentifiers to only delete the corresponding standalone baskets. basketIdentifiers can only be used for non-composite baskets.