[2026-10 RC Issue] `fetchAvailableDeliveryOptions` still returns only the cheapest rate

Products and Orders APIs
1

We are testing the new SubscriptionContractCalculation API on the 2026-10 release candidate and it has the same limitation the SubscriptionDraft API has had since 2021: only the cheapest shipping rate comes back, even when the subscription delivery profile has several rates for the zone.

What we ran

Store setup: a subscription delivery profile attached to the selling plan group, with three rates in the test zone (Ground $5, 2nd Day Air $25, Overnight $35). Checkout shows all three options for a subscription purchase’s first shipment (ie the customer can pick form all three for the first shipment).

Then for the resulting subscription we ran:

mutation {
  subscriptionContractUpdateCalculate(
    contractId: "gid://shopify/SubscriptionContract/..."
    contractUpdateInput: {
      withMerchandiseCustomizations: false
      deliveryMethod: {
        fetchAvailableDeliveryOptions: {
          address: { address1: "...", city: "...", provinceCode: "CA", countryCode: US, zip: "..." }
          withDeliveryCustomizations: true
        }
      }
    }
  ) {
    subscriptionContractCalculation {
      ... on SubscriptionContractCalculationPending { id }
    }
    userErrors { field message code }
  }
}

Then polled subscriptionContractCalculation(id:) and read deliveryOptions on SubscriptionContractCalculationSuccess.

What came back

One SubscriptionContractCalculationShippingOption (the $5 rate), one local delivery option and one pickup option. The cheapest of each delivery type, nothing else. Same result with withDeliveryCustomizations: false. Same result with subscriptionContractCreateCalculate for a new contract.

What the docs say

From the migration guide, section “Fetch delivery options”:

“The deliveryOptions field on SubscriptionContractCalculationSuccess returns the available delivery options that the calculation computed. This field replaces the SubscriptionDraft.deliveryOptions field from the SubscriptionDraft API, and returns all available options.”

“Fetching delivery options is opt-in. A calculation that sets or keeps a committed delivery method uses a faster path that doesn’t look up the full set of rates, so it doesn’t return the complete set of options. To fetch all available options for an address, provide fetchAvailableDeliveryOptions in the deliveryMethod input instead of a method.”

The worked example in the same guide shows two shipping options (Standard $5, Express $15) coming back from a single fetch. We cannot reproduce that but would love to learn how. I suspect it’s not possible.

Why this matters

The 2026-10 changelog says contract edits now run through the same checkout engine as Checkout and Draft Orders, and that this “keeps calculations consistent with checkout”. Checkout offers the customer every qualifying rate. A subscription contract edit through the same engine offers one. That is the one inconsistency subscription apps have been asking to have removed for years.

For our merchants this is not cosmetic. Expedited and cold-chain rates carry different prices and are used by compliance and fulfillment systems to decide whether an order can ship to a given state at a given service level. Today every subscription app has to either force the cheapest rate or build its own rate table outside Shopify, which drifts from the merchant’s real shipping profile.

History

This has been reported since at least November 2022 (“Multiple Shipping Rates for Subscriptions”, community thread). Shopify staff confirmed on November 8, 2022 that “at the moment we only display the cheapest shipping option for subscriptions at checkout”, and on June 14, 2023 that “this is in our radar” with no ETA. The original Subscriptions API roadmap page listed multiple shipping rates for subscriptions as a planned improvement; that page has since been removed from shopify.dev.

Questions

  1. Is the single-rate result on fetchAvailableDeliveryOptions the intended behavior for 2026-10, or a gap in the release candidate that will be closed before GA in October?
  2. If intended, what does “returns all available options” in the migration guide refer to? Is it only the union across delivery types (one shipping, one local delivery, one pickup) rather than all rates within a type?
  3. Is there any supported way today to obtain every qualifying shipping rate for a subscription contract and address, without reimplementing the delivery profile rules client-side?

We are about to decide between waiting for this API and building a parallel rate engine. A clear answer either way would save a lot of wasted work across every subscription app on the platform.

Happy to share a test store and the exact contract and calculation IDs with the team (here’s the latest test we tried: gid://shopify/SubscriptionContractCalculation/12316344622 in case it helps)

Thanks in advance!!

2

Hey @Brian_Singer :waving_hand:

Thanks for the detailed writeup - this matches what we’re seeing on our end.

Just confirming: this is current platform behaviour, not something specific to your setup or the RC. When a subscription delivery group is calculated, the options for each delivery type get reduced to the single cheapest one before they’re returned. That’s why withDeliveryCustomizations doesn’t change the result and why create and update behave the same way.

This is something we’re aware of and actively working on our end. I can’t share timing or guarantee it’ll land ahead of 2026-10 going stable/what the behaviour will look like, but did want to let you know this is on our radar.

On your questions:

  1. Not the intended end state.
  2. The migration guide is describing where this is headed rather than what the RC returns today - just to confirm
  3. Unfortunately, not at the moment.

Hope this helps a bit and let me know if I can clarify anything on our end here.

4

Very helpful! Thank you so much for the response @Alan_G!