Identify `CartDeliveryOption`'s that are attached to Recurring Shipments

Functions
1

Currently, it doesn’t seem possible within a shipping discount function to determine if a CartDeliveryOption belongs to a recurring shipment, or a standard shipping profile.

This means that when looping through the CartDeliveryOption options within the CartDeliveryGroups, you get options that you can’t actually do anything with (because you can’t discount recurring shipping methods).

It’d be great if you could check for this as a DeliveryMethod enum value within each CartDeliveryOption - i.e. current values are:

  • LOCAL
  • NONE
  • PICKUP_POINT
  • PICK_UP
  • RETAIL
  • SHIPPING
  • RECURRING_SHIPPING ← Add this one

image (10)
image (10)636×347 18.8 KB

2

Hey @Lewis :waving_hand: - hopefully I’m understanding correctly here, but you’re looking at just confirming if a particular checkout would result in a recurring shipment (like a subscription)?

Your right that there’s not a super easy way to definitively confirm this on the delivery method object itself, but you should be able to check for this against the line items in a cart/checkout by checking their attached selling plan object: SellingPlan

This is part of our overall Discounts Functions API though, with the Shipping Specific Discount Function being deprecated as of API version 2025-04 (more info here).

Hope this helps - let me know if I can clarify anything on my end here.

3

Hi @Alan_G - not quite.

I basically need to validate each shipping option, and exclude any that are part of the recurring Shipments group.

For reference, this is what’s returned from the input for the above screenshot. I’ve tried outputting the code value, but nothing displays anything that has any reference to the recurring shipment.

...
"deliveryGroups": [
      {
        "deliveryOptions": [
          {
            "handle": "661a541e41b7075363c798240fcb130d-85ae048ccd062bfb1bf47a5065c96b02",
            "title": "Standard FREE SHIPPING (5-10 business days)"
          }
        ]
      },
      {
        "deliveryOptions": [
          {
            "handle": "661a541e41b7075363c798240fcb130d-3b1a35fedacbf099b9e6122af097c218",
            "title": "Standard FREE SHIPPING (5-10 business days)"
          }
        ]
      },
      {
        "deliveryOptions": [
          {
            "handle": "661a541e41b7075363c798240fcb130d-44629de2ad7c90f1f5b0261e03eb0bdb",
            "title": "US Standard (5-7 business days)"
          }
        ]
      }
    ]
...

However, within that, there’s no way to split out the options that belong to the recurring shipment (other than title, but these are dynamic).

On a line item level, I can return the sellingPlan as suggested to identify lines that have subscriptions, but I need to do this on the deliveryOptions.

Hope that helps!

4

Hey @Lewis - ah understood! Thanks for clarifying. At the moment, you’re right, it’s a bit less than ideal to have to first identify which line items have selling plans, then determine which delivery options are associated with those subscription items external to the API responses itself.

It’s technically doable, but this mapping isn’t straightforward in the current API syntax - totally fair (you’d need to know the delivery methods beforehand which isn’t super helpful if you’re making a universal app). I can’t guarantee anything, but I will definitely do some more digging to see if this is something on our radar and loop back with you when I have more info. I can put through a feature request at the very least though, if that would be helpful.

I’ll get back in touch here when I have some more info :slight_smile:

6

Hey @Lewis :waving_hand: - just looping back here after speaking with the team. Adding something like RECURRING_SHIPPING as a DeliveryMethod enum value is definitely something we have on our radar and we’re hoping to add it in the near-ish term. Can’t provide an exact turnaround time, but I’ll get back in touch with you again in this thread to follow up once I have some more share-able info.

7

Hey @Alan_G - appreciate the follow up - the ENUM value would definitely help resolve this issue, so that would be great if we can get that pushed through asap!

Will keep my eyes peeled! :eyes: