We have an emerging use case where we need to identify which products in an order are part of a subscription vs a one-time purchase.
This data seems to be available when querying the order via the graphql api at the sellingPlanconnection, but I’m not seeing that information available in the line item properties in the order webhook json, either create or update.
Without these being present in the webhook payload it means we need to make API calls and use up quota as part of what should be purely background processing.
Am I missing something here? Is there some way to get this information included in the webhook payload?
You are correct that the order webhooks (such as order/create or order/updated) do not include the full selling plan or subscription information for each line item in their payload. The selling plan details (such as whether a line item is part of a subscription or a one-time purchase) are available via the GraphQL Admin API when querying an order, specifically through the sellingPlanAllocation field on each line item. However, this information is not present in the webhook payloads by default.
Is there a way to get this information in the webhook payload?
Currently, there is no built-in way to include the full selling plan or subscription details for each line item directly in the order webhook payload. The webhook payloads are not customizable to include additional fields like sellingPlanAllocation or sellingPlanId for line items.
What can you do?
-
You must make a follow-up API call to the Admin GraphQL API to fetch the order and its line items, including the sellingPlanAllocation field, to determine which products are part of a subscription.
-
This is a known limitation and is a common pain point for apps that need to process subscription data in the background.
Example: Fetching selling plan info for order line items
You can use the order query to fetch the selling plan allocation for each line item:
query GetOrderSellingPlans {
order(id: "gid://shopify/Order/1234567890") {
id
name
lineItems(first: 50) {
edges {
node {
id
title
quantity
sellingPlanAllocation {
sellingPlan {
id
name
}
}
}
}
}
}
}
That being said….adding a line item property is somehow a valid workaround, but it comes with important caveats:
-
Line item properties are arbitrary key-value pairs that can be attached to a line item at the time it is added to the cart or order.
-
These properties are included in the order webhook payload, so you can access them in your background processing without an extra API call.
-
However, line item properties are not automatically set by Shopify for subscription or selling plan information. You would need to ensure that your checkout or subscription app explicitly adds a property (e.g., "is_subscription": "true" or "selling_plan_id": "12345") when the item is added to the cart or order.
How to add a line item property
If you control the storefront or the app that adds subscription products to the cart, you can add a property like this:
items: [
{
quantity: 1,
id: 794864229,
properties: {
'_is_subscription': 'true',
'_selling_plan_id': '12345'
}
}
]
This property will then appear in the order webhook payload under the line item’s properties field.
Limitations
-
This approach only works if you can guarantee that the property is set at the time of cart or checkout creation.
-
If customers can purchase subscriptions through other means (e.g., third-party apps or channels you don’t control), those orders may not have the property set.
-
This is not a Shopify-supported or enforced method for tracking subscriptions, so it is only as reliable as your implementation. i.e if you do it on a theme level - your sales channels will not pick it up. Ideally the line item property should be added via shopify function at checkout.
Hope this helps
interesting idea, but yeah doesn’t work if we’re primarily processing order data from orders that we didn’t create/control
I take it there have been no indications or acknowledgement from shopify on this limitation?
yeah good point, line item properties is not something that would cover retroactive orders but that should not be an issue for order.create webhook. However for order.update - you can run an additional api call check if it’s subscription then update the line item property or not.