I have a product in Shopify with the weight set to 1 lb.
I’m using a solution based on the Carrier Service API, where the product weight is critical.
In the Carrier Service API, the weight is returned in grams. For this product, I’m getting 454 g.
The issue is that 1 lb = 453.59237 g, so there’s a rounding discrepancy.
When I convert this value back from grams to pounds, I get:
454 g = 1.00089867 lb
Our app uses weight-based calculation rules, where the merchant sets them according to the unit used in their store. Because of this inaccuracy in CSA, discrepancies occur.
Could you make the Carrier Service API return more precise weight data (e.g. with higher precision instead of rounding to whole grams)?
Hey @sebastian.pisula, thanks for flagging this, I’ll reach out to some folks internally to investigate this further and loop back with you once I have next steps to share. Speak with you as soon as I can on my end here!
Hey @sebastian.pisula - just following up here, our calculations for weight round up to the nearest whole number, which is why we’re seeing 454 g in this case. That said, I definitely realize it’s not the most ideal, so I’m happy to log a feature request for you so we can consider making adjustments to the method in the future.
Would you be open to sharing more about your use case if possible, including if you’re seeing any large scaling issues so I can properly advocate on my end since I do realize this could potentially cause headaches when it comes to managing parcel weights, etc? Hope to hear from you soon, happy to advocate for the feature on my end here for sure.
Thanks for getting back to me. From our perspective, this is a significant issue. Since our app relies on the Carrier Service API for weight-based shipping cost calculations, the rounding leads to inaccurate shipping rates being displayed to customers.
We’ve seen cases where this causes shoppers to abandon their carts because the cost does not properly reflect the actual weight of the order. Ultimately, this impacts merchants’ revenue.
We are the developers of a shipping app that integrates with the Carrier Service API, and we’ve observed this problem across multiple clients. That’s why we believe it’s important to address.Please let me know if this gives you enough context to move the request forward. Thanks again for your help in advocating for this.
Thanks @sebastian.pisula for following up here, really appreciate your perspective on this and as I mentioned, I can see how it’s not the most ideal limitation. I can’t guarantee anything on my end here, but I will reach back out to our product team to see if I can log a feature request for you at the very least as I mentioned/to see if there is a way to expedite this.
I’ll be in touch again here in the thread with more info as soon as I have that for you.
Hi @sebastian.pisula, thanks for your patience on this and for following up.
I was able to do some investigating internally, and did just want to confirm the rounding to whole grams is intentional behavior in the Carrier Service API and likely won’t be updated in the near term, generally because most shipping carriers work with whole gram formats.
I do understand this creates real challenges for weight-based calculation apps like yours, though, so in the meantime, one workaround I wanted to share in case you haven’t look at it as an option would be to you store precise weight values in a product metafield and reference that directly on your side instead of relying on the CS API weight field if that makes (although I know this adds a bit of toil to your flow)
I’d like to log a feature request for higher precision weight data on your behalf. I can’t promise if or when it might be addressed, but I will advocate as best I can with the right folks for you, so I did just want to see if that works for you/if I can share any further feedback. Hope to hear from you soon.
We’ve noticed this too - customers will checkout with 4 2.5g products, and the summed weight will be 12g instead of 10g.
The solution for us was to synchronize all product weight data and do the conversion locally rather than depending on value in the Carrier Service API. Metafields don’t get passed in CCS calls, so that won’t really work for us.
As @NickLozon already pointed out, metafields are not passed in the requests — fetching them would require additional API calls. To be honest, I would prefer to rely on data coming directly from the product rather than from metafields. On top of that, this approach is not really suitable for us because you expect Carrier Service API responses in under 500 ms (a Built for Shopify requirement).
At the moment, the only sensible solution is the one @NickLozon is using. That said, I do have a fairly clear vision of how this could work in an ideal scenario.
Similar to the Function API — and more specifically the Delivery Customization Function API — an ideal solution would be the ability to define an Input where I could specify exactly which fields I need in the request, for example:
The response would remain the same as it is today. If I needed additional data, I could simply request it in the Input. I believe this kind of approach would be much more flexible and universal.
What do you think? Or do you perhaps already have something similar planned for implementation?
You’re right that the metafield workaround would make running up against the 500ms response requirement a bit togher, and I appreciate you folks mentioning that. The Function API-style input query approach you’ve described makes a lot of sense to me, especially since that pattern already exists with Delivery Customization and provides exactly the kind of flexibility you’re describing.
I can’t share whether something like this is already on the roadmap for Carrier Services, but I’m going to log this as a feature request and include the architectural context you’ve shared here since I think it makes a strong case. I can’t make any promises on timelines, but I’ll advocate for it where I can. Thanks again for the thoughtful feedback!