Determining source of a ShippingLine on Recharge subscription orders

[Alexander_Strand]

Hi all,

I’m working on a WMS integration that connects to many different Shopify stores via the GraphQL API.

The example below is from a store using Recharge subscriptions, but we don’t currently know whether the same behavior occurs with other subscription providers.

We’ve noticed that a subscription order shipping line can look something like this:

{
 "code": "0340_109909",
 "source": "shopify",
 "title": "Bring pick-up parcel • 1.0 km • Købmanden I Rudemarken",
 "carrierIdentifier": null,
 "shippingRateHandle": "shopify-0340_109909-25.00"
}

The challenge is that the code is provider-specific, in this case originating from the Bring plugin, while the source is reported as "shopify". For the equivalent non-subscription order, the source would have been "Posten Norge".

As a third-party fulfillment system, we need a reliable way to determine how a shipping line code should be interpreted and parsed, which we reliably can do when the source field states the provider. Potentially multiple shipping provider apps could use ambiguous code formats, so trying to parse the code without knowing which provider generated it not desirable.

My questions are:

1. Is the loss of source provider information on recurring subscription orders expected behavior?
2. Is there any API field that identifies the shipping app or carrier service that originally generated a ShippingLine on Recharge subscription orders (or subscription orders in general, I don’t really know the difference)?
3. If no such information is available, what is the recommended approach for integrations that need to interpret provider-specific shipping codes from multiple different providers?

Has anyone else run into this problem when working with subscription orders and shipping integrations?

Thanks!

[KyleG-Shopify]

Hey @Alexander_Strand,

I did some testing against the Admin API and can confirm the same behavior. On recurring subscription orders created outside of checkout, ShippingLine.source defaults to “shopify” and carrierIdentifier comes back null, even though the provider-specific code is preserved.

I checked every Admin API field that could plausibly carry carrier identity and none of them do. Some other similar threads here as well:

Does REST Admin API preserve shipping_lines.source when creating orders via /orders.json?

Hi everyone, I’m creating duplicate Shopify orders via an automation tool using the Admin API. Context: The original order has a shipping line from a carrier/app: source: "Izprati.bg" code: "v2:..." The shipping line represents a Speedy service point / pickup office. The carrier app later reads this data to generate the correct label. When I duplicate the order with GraphQL orderCreate, I can copy shippingLines.title and shippingLines.code, but I cannot set shippingLines.source. So I tri…

Carrier Service: shipping_lines code replaced with generic "Shipping" in orders/paid

Summary We’re a Carrier Service app that provides shipping rates at checkout via the POST /carrier_service callback. We’ve noticed that for some paid orders, the shipping_lines in the orders/paid webhook contains a generic "Shipping" code instead of the service_code we originally provided in our rates response. What we send (Carrier Service callback response) { "rates": [ …

For now, cross-referencing Recharge’s API for the original checkout shipping selection is the best workaround on historical orders. I’ve also filed this internally as a feature request on your behalf so the team is aware of the gap.