Allow EDD and checkout-assignment APIs to accept a reservationId, consider the reservation when computing the promise, and continue sourcing rule evaluation.

The following APIs should accept a reservationId (single or list, at header or line level) in the request payload. When present, the API should consider the reservation — using the held quantity at the reserved node or network as the basis for the promise , so the EDD is computed against the inventory already held for this caller. Reservations not passed are ignored, preserving today's behavior for the standard pre-purchase flow.

/promising/{tenantId}/v2/edd
/promising/{tenantId}/v1/cachedEDD
/promising/{tenantId}/v2/calculateCheckoutAssignments
/promising/{tenantId}/v2/calculateCheckoutAssignmentsUsingCosts

ReservationID should be honoured at linelevel or headerlevel of cart

Important Note:

Sourcing rule evaluation must continue when reservationId is passed. The reservation locks the node and quantity; sourcing rules continue to drive carrier service selection and other item-level decisions (based on product type, classification, category, weight, dimensions, etc.). Hence We need sourcing rule evaluation to continue to happen.

What is your industry? Retail

How will this idea be used?

Pre-purchase flow with reserve-at-add-to-cart:

Customer adds an item to cart (ATP = 1) → Reserve API returns reservationId = R1; ATP drops to 0.
Customer navigates to PDP, cart, checkout, or amends the cart. The page calls the EDD or checkout-assignment API to render the delivery promise.

Today: ATP = 0 → API returns no-inventory-to-promise → no EDD can be rendered, even though R1 holds the unit for this customer.

With this enhancement, the storefront passes R1 in the request. The API:

Considers the reservation and picks up the held unit at the reserved node/network for promise computation.
Continues to evaluate sourcing rules — for carrier service selection and other item-level decisions (e.g., hazardous items routed to specific carriers, oversized items to dedicated services). For multi-item carts, sourcing evaluates per line, not globally.
Returns the correct EDD against the held unit.

Applies across PDP, cart, checkout (calculateCheckoutAssignments / calculateCheckoutAssignmentsUsingCosts with R1), and cart amendment / re-promise (edd, cachedEDD).

Post comment

Admin

Sampson Wong

May 27, 2026

Without going into implementation details at this stage, could you share the underlying business use case and flow so we can better understand the requirement and the dependency on a pre-determined reservation ID?

From a product perspective, the current calculateCheckoutAssignments API already supports node-level constraint via overrideNodeList at the cart line level. This allows the caller to restrict sourcing to a specific node, effectively achieving a similar outcome to a locked-node reservation when the intent is to anchor fulfillment to a predefined location.

Example:
POST /promising/$tenant/v2/calculateCheckoutAssignments
{
"deliveryMethod": "SHP",
"referenceTime": "1900-01-01T00:00:00.000Z",
"capacityUomToConsider": "UNITS",
"destination": {
"format": "ADDRESS",
"value": {
"countryCode": "US",
"postalCode": "12345",
"timezone": "America/New_York"
}
},
"cartLines": [
{
"lineNo": 1,
"overrideNodeList": [
"STORE_TO_USE"
],
"itemInfo": {
"itemId": "I1",
"unitOfMeasure": "EACH"
},
"quantity": 1
}
]
}
In this model, Promising continues to perform inventory availability checks and applies sourcing constraints and downstream rules (including carrier/service selection), while respecting the node restriction provided.

From a design standpoint, introducing a reservationId as an additional input would duplicate existing node-constraint behavior, but shift responsibility for node selection to an external system. In most standard implementations, this is typically handled within sourcing rules and availability logic rather than pre-reserving nodes upstream.

That said, we will log this as an enhancement request for review in future roadmap discussions. In the meantime, we recommend validating whether overrideNodeList can satisfy the intended fulfillment constraint before introducing a reservation-driven model.

1 reply
Hide replies

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.

Shape the future of IBM!

Search existing ideas

Post your ideas

Specific links you will want to bookmark for future use

Allow EDD and checkout-assignment APIs to accept a reservationId, consider the reservation when computing the promise, and continue sourcing rule evaluation.

Please enter your email address

RELATED IDEAS

Allow EDD and checkout-assignment APIs to accept a reservationId, consider the reservation when computing the promise, and continue sourcing rule evaluation.