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": [                                      
    {
      "service_code": "envío-europa-2349",
      "service_name": "Standard Delivery",
      "total_price": 990,                                                                                                                                                          
      "currency": "EUR",
      "min_delivery_date": "2026-03-28",                                                                                                                                           
      "max_delivery_date": "2026-04-01"                                                                                                                                            
    }                                             
  ]                                                                                                                                                                                
} 

What we receive (orders/paid webhook → shipping_lines)

{                                                                                                                                                                                  
 "shipping_lines": [                                                              
   {                                             
     "code": "Shipping",
     "title": "Shipping",
     "source": "Reveni",                                                                                                                                                          
     "carrier_identifier": "9bcc2260c87fcc7a3e1ad8eb2e70117c"
   }                                                                                                                                                                              
 ]                                                                                
} 

Expected behavior

The code field in shipping_lines should preserve our original service_code value (“envío-europa-2349”), as documented in the
CarrierService.

Actual behavior

Both code and title are replaced with a generic “Shipping” string. The source field correctly shows our app name, confirming the customer did select our rate at checkout.

Impact

We rely on service_code to match the selected rate back to our internal shipping method. When Shopify replaces it, we can’t determine which specific method the customer chose and
have to fall back to a generic region-based match.

Additional details

  • This does not happen on every order — only some.
  • We haven’t been able to identify a clear pattern for when it occurs vs. when the code is preserved correctly.
  • Confirmed via the Admin GraphQL API (order.shippingLine) — the data is already generic there too, so it’s not a webhook serialization issue.
  • Tested across multiple stores with different shipping method configurations.

Has anyone else experienced this? Is this a known issue or is there something we should change in our rates response to ensure service_code is preserved?

Hey @Reveni_Dev :waving_hand: Your carrier service response looks correct, and the fact that source shows “Reveni” confirms your carrier service was involved in the rate. The generic “Shipping” replacement of code and title is almost certainly caused by Shopify’s shipping rate consolidation at checkout.

When an order contains items that span multiple delivery allocations (different shipping profiles, different fulfillment locations, or different location groups within a profile), Shopify consolidates the rates into a single delivery option. If the rate names from each allocation don’t match exactly, Shopify creates a fallback option with the title “Shipping”. The code field also becomes “Shipping” when the cheapest rates from each allocation have different codes, which is very likely with your dynamic format like envio-europa-2349. The source field is preserved as long as all candidates came from the same carrier service, which is why you still see “Reveni”.

This would explain the intermittent nature you’re seeing. Orders where all items belong to a single shipping profile and fulfillment location won’t trigger consolidation, so your service_code comes through fine. Orders that cross profile or location boundaries hit the consolidation path.

To confirm, can you check whether the affected orders share any of these traits?

  1. Products from multiple shipping profiles in the same order

  2. Products fulfilled from different locations

  3. Stores with multiple location groups in their shipping settings

If consolidation is the cause, the workaround is to return both a consistent service_name and a consistent service_code across all rate requests for a given shipping method. The DeliveryCarrierService docs note that service_code should be “stable and consistent across requests for the same shipping option.” When names match across allocations, Shopify uses name-based consolidation instead of the fallback, and code is preserved if it’s also identical. If names match but codes differ, the code falls back to the service name (e.g., “Standard Delivery”) rather than your original service_code.

1 Like