Introduction

Basket submission in EAC is centred on two related concepts: baskets and basket composites. A basket is the market object that contains the parent and child orders for one unit on one service window. A basket composite is the submission container used to manage one or more baskets together.

A Basket is a grouping of sell orders for one unit, one service type, and exactly one service window. It contains exactly one parent order and may contain child and substitutable child orders.

A basket can be submitted on its own or as part of a basket composite:

• Use standalone baskets only for backward compatibility with the legacy enterBaskets flow.
• Use basket composites for all new integrations and whenever you need grouping structures or newer basket submission capabilities.

• Looped baskets are baskets that must be accepted or rejected together by the algorithm.
• Looped family is the grouping of those looped baskets. With enterBaskets , this can be represented with familyName . With the basket composite APIs, the recommended way is to group baskets explicitly under loopFamilies .
• Flexible group is a grouping of consecutive baskets with a minimum consecutive acceptance condition. Flexible groups are submitted through basket composites.
• Linked service windows are service windows that NESO decides to treat together for a specific service. If MPs bid on those linked service windows, they must submit a consistent grouped structure. Refer to Service windows for the detailed rules.

The recommended long-term direction for MPs is the basket composite API family: enterBasketsComposite , enterBasketsComposites , and removeBasketsComposites . enterBaskets remains available for backward compatibility, but new features and products may not be integrated into that legacy API.