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?